Модель актера для замены модели резьбы?

Я прочитал главу в книге (Семь языков в семи неделях от Брюса А. Тейта) о Мац (Изобретатель Руби), в которой говорится: "Я бы удалил нить и добавил актеров или некоторые другие более продвинутые функции concurrency".

  • Почему и как модель актера может быть усовершенствованной моделью concurrency, которая заменяет потоки?
  • Какие еще модели являются "расширенной моделью concurrency"?

Ответы

Ответ 1

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

Идея актеров состоит в том, чтобы иметь отдельные потоки управления (процессы на языке Эрланга), которые общаются исключительно путем передачи сообщений. Более традиционной моделью программирования было бы совместное использование памяти и координация обмена данными между потоками с использованием мьютексов. Это все еще происходит под поверхностью в модели актера, но детали абстрагируются, а программисту даются надежные примитивы, основанные на передаче сообщений.

Одним из важных моментов является то, что актеры не обязательно отображают 1-1 для потоков - в случае с Erlang они определенно не работают - обычно будет много процессов Erlang на поток ядра. Таким образом, должен быть планировщик, который назначает участников потокам, и эта деталь также абстрагируется от прикладного программиста.

Если вас интересует модель актера, вы можете посмотреть, как она работает в Erlang или Scala.

Если вас интересуют другие типы новой concurrency жары, вы можете посмотреть транзакционную память программного обеспечения, другой подход который можно найти в clojure и haskell.

Следует отметить, что многие более агрессивные попытки создания продвинутых моделей concurrency, как представляется, происходят на функциональных языках. Возможно, из-за веры (я сам выпиваю часть этой kool-помощи), что неизменность делает concurrency намного проще.

Ответ 2

Я задал этот вопрос своим любимым и жду ответа, но, поскольку его все еще нет, вот моя..

Почему и как модель актера может быть расширенная модель 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

См. Программирование потока данных. Это подход, который является слоем поверх обычного дизайна ООП. В некоторых словах:

  • есть сцена, в которой находятся компоненты;
  • Компоненты имеют порты: Производители (вывод, которые генерируют сообщения) и Потребители (ввод, какие сообщения процесса);
  • Существуют сообщения, предварительно определенные между компонентами: один порт производителя компонента связывается с другим пользователем.

Программирование происходит на 3-х уровнях:

  • запись системы потока данных (язык, структура/сервер, компонентный API),
  • запись Компоненты (системные, базовые и ориентированные на домен),
  • создание программы потока данных: размещение компонентов в сцене и определение сообщений между ними.

Статьи в Википедии - хорошая отправная точка для понимания бизнеса: http://en.wikipedia.org/wiki/Flow-based_programming См. Также "Модель актера", "Программирование потока данных" и т.д.