Когда нужно использовать модель Actor?
Едва кажется стоящим того, так как можно сделать следующее:
var o = incrediblyLongObjectNameThatNoOneWouldUse;
o.name = "Bob";
o.age = "50";
2 ответа
Учитывая некоторую проблему параллелизма, что бы вы искали, чтобы решить, использовать ли акторы или нет?
Сначала я хотел бы определить проблему ... основная мотивация - ускорение вложенный цикл for или рекурсия? В таком случае подход, основанный на простых задачах или подход с параллельным циклом, скорее всего, будет хорошо работать для вас (а не для субъектов).
Однако, если у вас более сложная система, которая включает зависимости и координацию общего состояния, то подход актора может помочь. В частности, за счет использования акторов и семантики передачи сообщений часто можно избежать использования явных блокировок для защиты общего состояния, фактически создавая копии этого состояния (сообщений) и реагируя на них.
Вы можете сделать это довольно легко с помощью классических задач синхронизации, таких как обедающие философы и проблема спящих парикмахеров. Но вы также можете использовать «актера», чтобы помочь с более современными шаблонами, то есть ваш фасад может быть актером, ваше представление модели и контроллер также могут быть акторами, которые общаются друг с другом.
Еще одна вещь, которую я заметил, это эта семантика акторов изучается большинством разработчиков и «безопаснее», чем их заблокированные аналоги. Это связано с тем, что они повышают уровень абстракции и позволяют сосредоточиться на координации доступа к этим данным, а не на защите всех доступов к данным с помощью блокировок. В качестве примера представьте, что у вас есть простой класс с элементом данных. Если вы решите установить блокировку в этом классе для защиты доступа к этому члену данных, тогда любые методы в этом классе должны будут гарантировать, что они получают доступ к этому члену данных под блокировкой.
The usage of Actor is "natural" in at least two cases:
- When you can decompose your problem in a set of independent tasks.
- When you can decompose your problem in a set of tasks linked by a clear workflow (ie. dataflow programming).
For instance, if you process complex data using a series of filters, it is easy to use a pipeline of actors where each actor receives data from an upstream actor and sets data to a downstream actor.
Of course, this data-flow must not be linear and if a step is slow in your pipeline, instead you can use a pool of actors doing the same job. Another way of solving the load balancing problems would be to use instead a demand-driven approach organized with a kind of virtual Kanban system.
Of course, you will need synchronization between actors in almost all interesting cases, but contrary to the classic multi-thread approach, this synchronization is really "concrete". You can imagine guys in a factory, imagine possible problems (workers run out of the job to do, upstream operations is too fast and intermediate products need a huge storage place, etc.) By analogy, you can then find a solution more easily.