Что такое параллелизм, управляемый событиями?

Question

Я начинаю изучать Scala и функциональное программирование. Я читал эту книгу! Программирование scala: решение многоядерной сложности на виртуальной машине Java ». В первой главе я увидел слово« параллелизм с событиями »и модель« Актер ». Прежде чем продолжить чтение этой книги, я хочу, чтобы идея о Event-Driven параллельности или Actor модели.

Что такое Event-Driven параллелизм, и как это связано с Actor модели?

Answer 1

Событие Driven модель программирования включает в себя регистрацию кода для запуска, когда данные срабатывает событие Например, вместо вызова метода, который возвращает некоторые данные из базы данных:

val user = db.getUser(1) 
println(user.name) 

Y НУ может вместо того, чтобы зарегистрировать функцию обратного вызова для запуска, когда данные готовы:

db.getUser(1, u => println(u.name)) 

В первом примере, не параллельность не происходит; Текущий поток будет блокироваться до тех пор, пока db.getUser(1) не вернет данные из базы данных. Во втором примере db.getUser немедленно вернется и продолжит выполнение следующего кода в программе. Параллельно с этим обратный вызов u => println(u.name) будет выполнен в какой-то момент в будущем.

Некоторые люди предпочитают второй подход, так как это не значит, что голодны головоломки. Нити нуждаются в сидении, ожидая медленного ввода-вывода.

Модель Actor - пример того, как концепции Event-Driven могут использоваться, чтобы помочь программисту легко писать параллельные программы.

Сверхвысокого уровня, Актеры - это объекты, которые определяют последовательность обработчиков сообщений, управляемых событиями, которые срабатывают, когда Актер получает сообщения. В Акке каждый экземпляр Актера является единственным Режимом, однако, когда многие из этих Актеров собраны вместе, они создают систему с параллелизмом.

Например, Актер A может отправлять сообщения Актеру B и C в параллель. Актер B и C могут отправлять сообщения обратно Актеру A. Актер A имел бы обработчики сообщений, чтобы получать эти сообщения и вести себя по своему желанию.

Чтобы узнать больше о модели Actor, я бы рекомендовал прочитать документацию Akka. Это действительно хорошо написано: http://doc.akka.io/docs/akka/2.1.4/

Там также много в хорошей документации вокруг веб о Event Driven параллельности, что нам гораздо более подробно, чем то, что я написал здесь. http://berb.github.io/diploma-thesis/original/055_events.html

Answer 2

Ответ Theon дает хороший современный обзор. Я хотел бы добавить историческую перспективу.

Тони Хоар и Роберт Милнер разработали математическую алгебру для анализа параллельных систем (передача последовательных процессов, CSP и коммуникационных параллельных систем, CCS). Оба они выглядят как тяжелая математика для большинства из нас, но практическое применение является относительно простым. CSP привел непосредственно к языку программирования Occam среди других, причем Go является самым новым примером. CCS привел к исчислению Pi и мобильности контактирующих каналов, функции, которая является частью Go и была добавлена ​​в Occam за последнее десятилетие или около того.

CSP моделирует параллелизм только путем рассмотрения автоматических объектов («процессы», v.легкие вещи, такие как зеленые потоки), взаимодействующие просто путем обмена событиями. Среда для прохождения событий идет по каналам. Процессам, возможно, придется иметь дело с несколькими входами или выходами, и они делают это, выбирая сначала готовое событие. События обычно переносят данные от отправителя к получателю.

Принципиальная особенность модели CSP заключается в том, что пара процессов взаимодействует только тогда, когда они готовы - на практике это приводит к тому, что обычно называют синхронной связью. Тем не менее, фактические реализации (Go, Occam, Akka) позволяют буферизовать каналы (нормальное состояние в Akka), так что вместо этого блокировка обмена событиями фактически развязывается.

Таким образом, управляемая событиями система на основе CSP - это действительно потоковая сеть процессов, связанных каналами.

Помимо интерпретации событий CSP, связанных с событиями, были и другие. Важным примером является подход «event-wheel», когда-то популярный для моделирования параллельных систем, в то время как фактически имел единственный поток обработки. Такие системы обрабатывают события, помещая их в очередь обработки и обрабатывая их должным образом, обычно посредством обратного вызова. Хорошим примером является механизм обработки событий Java Swing. Были и другие, например. для механизмов моделирования на основе времени. Можно подумать о модели Javascript/NodeJS как подходящей для этой категории.

Таким образом, колесо событий было способом выражения параллелизма, но без параллелизма.

Ирония заключается в том, что два подхода, которые я описал выше, описаны как события, но то, что они подразумевают под действием события, различно в каждом случае. В одном случае аппаратные элементы соединены вместе; в другом, почти все действия выполняются обратными вызовами. Подход CSP утверждает, что он масштабируется, потому что он полностью сложен; это, естественно, адепт при параллельном исполнении. Если есть какие-то причины одобрить друг друга, это, вероятно, это.