Что движет событие параллелизма?
Я начинаю изучать Scala и функционального программирования. Я читал книгу !Программирование scala: решение многоядерной сложности на виртуальной машине Java". В первой главе я видел модель параллелизма и актера, управляемую событиями. Прежде чем продолжить чтение этой книги, я хочу получить представление о параллелизме, управляемом событиями, или модели актера.
Что такое параллелизм, управляемый событиями, и как он связан с моделью актора?
2 ответов
модель программирования, управляемая событиями, включает регистрацию кода для запуска при возникновении данного события. Например, вместо вызова метода, который возвращает некоторые данные из базы данных:
val user = db.getUser(1)
println(user.name)
вместо этого вы можете зарегистрировать обратный вызов для запуска, когда данные будут готовы:
db.getUser(1, u => println(u.name))
в первом примере параллелизма не происходило; текущий поток будет блокировать до db.getUser(1) возвращаемые данные из базы данных. Во втором примере db.getUser вернутся немедленно и продолжайте выполнение следующего кода в программе. Параллельно с этим, обратный вызов u => println(u.name) будет выполняться в какой-то момент в будущем.
некоторые люди предпочитают второй подход, поскольку это не означает, что голодные потоки памяти напрасно сидят в ожидании медленного ввода-вывода.
модель Actor является примером того, как концепции, управляемые событиями, могут использоваться, чтобы помочь программисту легко писать параллельные программы.
от супер высокого level, Actors-это объекты, определяющие серию обработчиков сообщений, управляемых событиями, которые запускаются при получении сообщений актором. В Akka каждый экземпляр актора однопоточен, однако, когда многие из этих акторов объединены, они создают систему с параллелизмом.
например, актер A может отправлять сообщения актер B и C параллельно. Актер B и C может отправлять сообщения актеру A. Актер A бы сообщения обработчики для получения этих сообщений и вести себя так, как требуется.
чтобы узнать больше о модели актера, я бы рекомендовал прочитать документацию Akka. Это действительно хорошо написано: http://doc.akka.io/docs/akka/2.1.4/
есть также много хорошей документации по всему интернету о параллелизме, управляемом событиями, что нам гораздо более подробно, чем то, что я написал здесь. http://berb.github.io/diploma-thesis/original/055_events.html
ответ Теона обеспечивает хороший современный обзор. Я хотел бы добавить историческую перспективу.
Тони хор и Роберт Милнер разработали математическую алгебру для анализа параллельных систем (сообщающиеся последовательные процессы, CSP и сообщающиеся параллельные системы, CCS). Оба они выглядят как тяжелая математика для большинства из нас, но практическое применение относительно просто. CSP привел непосредственно к языку программирования Occam среди других, с Go быть самым новым примером. CCS привел к исчислению Pi и мобильности концов каналов связи, функция, которая является частью Go и была добавлена в Occam в последнее десятилетие или около того.
моделей параллелизма сугубо с учетом automomous лиц ("процессы", В. легкие вещи, как зеленые нити), взаимодействующих просто биржа. Среда для передачи событий проходит по каналам. Процессы могут иметь дело с несколькими входами или выходами, и они делают это, выбирая событие что готов первым. События обычно переносят данные от отправителя к получателю.
принципиальной особенностью модели CSP является то, что пара процессов вступает в коммуникацию только тогда, когда оба готовы - в практическом плане это приводит к тому, что обычно называют "синхронной" коммуникацией. Однако фактические реализации (Go, Occam, Akka) позволяют буферизировать каналы (нормальное состояние в Akka), так что обмен событиями lock-step часто фактически развязывается вместо.
таким образом, в целом, управляемая событиями CSP - система на самом деле является сетью потоков данных процессов, связанных каналами.
помимо интерпретации CSP событий, были и другие. Важным примером является подход "колесо событий", когда-то популярный для моделирования параллельных систем, но фактически имеющий один поток обработки. Такие системы обрабатывают события, помещая их в очередь обработки и обрабатывая их должным образом, обычно через обратный звонок. Хорошим примером является механизм обработки событий Java Swing. Были и другие, например, для двигателей моделирования, основанных на времени. Можно подумать, что модель Javascript / NodeJS также вписывается в эту категорию.
таким образом, колесо событий было способом выразить параллелизм, но без параллелизма.
ирония заключается в том, что два подхода, которые я описал выше, описываются как управляемые событиями, но то, что они подразумевают под управляемыми событиями, отличается в каждом случае. В одном случае аппаратно-подобные объекты соединяются вместе; в другом почти все действия выполняются обратными вызовами. Подход CSP утверждает, что он масштабируемый, потому что он полностью композиционный; он, естественно, адепт параллельного выполнения. Если и есть какие-то причины отдавать предпочтение одной из них перед другой, то это, вероятно, они.