Я прочитал главу в книге (Семь языков в семи неделях от Брюса А. Тейта) о Мац (Изобретатель Руби), в которой говорится: "Я бы удалил нить и добавил актеров или некоторые другие более продвинутые функции concurrency".
Это не так, что модель актера заменит потоки; на уровне процессора процессы будут по-прежнему иметь несколько потоков, которые планируются и запускаются на процессорных ядрах. Идея актеров заключается в том, чтобы заменить эту сложную сложность моделью, которая, по мнению ее сторонников, упрощает программистам писать надежный код.
Идея актеров состоит в том, чтобы иметь отдельные потоки управления (процессы на языке Эрланга), которые общаются исключительно путем передачи сообщений. Более традиционной моделью программирования было бы совместное использование памяти и координация обмена данными между потоками с использованием мьютексов. Это все еще происходит под поверхностью в модели актера, но детали абстрагируются, а программисту даются надежные примитивы, основанные на передаче сообщений.
Одним из важных моментов является то, что актеры не обязательно отображают 1-1 для потоков - в случае с Erlang они определенно не работают - обычно будет много процессов Erlang на поток ядра. Таким образом, должен быть планировщик, который назначает участников потокам, и эта деталь также абстрагируется от прикладного программиста.
Если вас интересует модель актера, вы можете посмотреть, как она работает в Erlang или Scala.
Если вас интересуют другие типы новой concurrency жары, вы можете посмотреть транзакционную память программного обеспечения, другой подход который можно найти в clojure и haskell.
Следует отметить, что многие более агрессивные попытки создания продвинутых моделей concurrency, как представляется, происходят на функциональных языках. Возможно, из-за веры (я сам выпиваю часть этой kool-помощи), что неизменность делает concurrency намного проще.
Я задал этот вопрос своим любимым и жду ответа, но, поскольку его все еще нет, вот моя..
Почему и как модель актера может быть расширенная модель concurrency, которая заменяет резьбу?
Актеры могут избавиться от изменчивого общего состояния, что очень сложно правильно закодировать. (Мое понимание таково) actors может в основном мыслиться как объекты со своими потоками. Вы отправляете сообщения между участниками, которые будут поставлены в очередь и потреблены потоком внутри актера. Таким образом, любое состояние в актере инкапсулируется и не будет использоваться. Поэтому легко закодировать код.
см. также http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
Какие еще модели являются "продвинутыми" concurrency model '?
см. http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
См. Программирование потока данных. Это подход, который является слоем поверх обычного дизайна ООП. В некоторых словах:
Программирование происходит на 3-х уровнях:
Статьи в Википедии - хорошая отправная точка для понимания бизнеса: http://en.wikipedia.org/wiki/Flow-based_programming См. Также "Модель актера", "Программирование потока данных" и т.д.
Пожалуйста, следуйте следующей статье
Также см.