Я прочитал главу в книге (Семь языков в семи неделях от Брюса А. Тейта) о Мац (Изобретатель Руби), в которой говорилось, что «я удалю поток и добавлю актеров или другие более продвинутые функции параллелизма».Модель для замены модели резьбы?
Это не так много, что модель актер заменит темы; на уровне процессора процессы будут по-прежнему иметь несколько потоков, которые планируются и запускаются на процессорных ядрах. Идея актеров заключается в том, чтобы заменить эту сложную сложность моделью, которая, по мнению ее сторонников, упрощает программистам писать надежный код.
Идея актеров состоит в том, чтобы иметь отдельные потоки управления (процессы на языке Эрланга), которые общаются исключительно путем передачи сообщений. Более традиционной моделью программирования было бы совместное использование памяти и координация обмена данными между потоками с использованием мьютексов. Это все еще происходит под поверхностью в модели актера, но детали абстрагируются, а программисту даются надежные примитивы, основанные на передаче сообщений.
Важным моментом является то, что актеры не обязательно отображают 1-1 в потоки - в случае с Erlang они определенно не работают - обычно будет много процессов Erlang для каждого потока ядра. Таким образом, должен быть планировщик, который назначает участников потокам, и эта деталь также абстрагируется от прикладного программиста.
Если вас интересует модель актера, вы можете посмотреть, как она работает в Erlang или Scala.
Если вы заинтересованы в других типах новой параллелизма, вы можете посмотреть на software transactional memory, другой подход, который можно найти в clojure и haskell.
Следует отметить, что многие более агрессивные попытки создания современных моделей параллелизма, по-видимому, происходят на функциональных языках.Возможно, из-за веры (я сам выпиваю часть этого kool-aid), что неизменность делает параллелизм намного проще.
Я сделал этот вопрос мой любимый и жду ответов, но так как там до сих пор нет, вот мой ..
Почему и как модель актер может быть продвинутая модель параллелизм что заменяет резьбу?
Актеры могут избавиться от изменяемого общего состояния, что очень сложно правильно кодировать. (Я понимаю, что) actors может в основном мыслиться как объекты со своими потоками. Вы отправляете сообщения между участниками, которые будут поставлены в очередь и потреблены потоком внутри актера. Таким образом, любое состояние в актере инкапсулируется и не будет использоваться. Так что легко закодировать правильно.
смотри также http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
Какие еще модели являются "продвинутыми параллелизм модель?
см http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009
См. Программирование потока данных. Это подход, который является слоем поверх обычного дизайна ООП. В некоторых словах:
Программирование происходит на 3 слоя:
Википедии являются хорошей отправной точкой для понимания бизнеса: http://en.wikipedia.org/wiki/Flow-based_programming Смотрите также "модель актер", "программирование" потоков данных и т.д.
Я не уверен, что я бы назвал Dataflow слоем поверх ООП, больше альтернативой ООП с некоторым концептуальным кроссовером. Вы могли бы сказать, что OOP в соответствии с Smalltalk - это ориентированный на сообщения язык, который является тем, что касается потока данных. –
Реализация системы потока данных требует OOP (или, по крайней мере, это рекомендуется, естественным образом), в зависимости от архитектуры DF. Я написал DF-систему, где диспетчер и компоненты написаны на C++, соединения и параметры определяются с использованием языка скриптов propiatery, который скомпилирован в код C++, а конечным результатом является исполняемый файл a.out/ELF. Итак, базовая архитектура OOP, на ней построена DF-система. (Классы: сообщение, порт, потребитель, производитель, компонент (реферат) и т. Д. И, конечно, много классов компонентов). – ern0
Пожалуйста, следующий документ
Сначала я подумал, что это шутка, учитывая все товарные знаки в названии. –
Я пошел дальше и скажу, что неизменность повышает надежность системы. Параллельность - это один из аспектов сложности программного обеспечения, где разница в надежности очевидна. Очень сложные системы могут извлечь выгоду из использования неизменяемости даже без необходимости решения проблем параллелизма. –
Кроме того, помните, что модель актера также может применяться в сети, для разработки асинхронной модели обработки запросов. На самом деле, учитывая, что многоядерность будет правилом, эта абстракция может быть даже интересной на уровне os api (по крайней мере, для меня). – Coyote21