Когда следует использовать модель актера?
Это, конечно, не гарантирует безблокировочную среду.
Актер A может ждать сообщения от B, пока B ждет A.
Кроме того, если субъект должен убедиться, что его сообщение было обработано, прежде чем перейти к следующей задаче, он должен будет отправить сообщение и дождаться сообщения "Ваше сообщение было обработано" вместо прямой блокировки.
В чем сила модели?
Учитывая некоторую проблему concurrency, что бы вы хотели решить, использовать ли актеров или нет?
Сначала я бы посмотрел, чтобы определить проблему... является основной мотивацией ускорения вложенного цикла или рекурсии? Если так, то простой подход на основе задачи или параллельный цикл, скорее всего, сработает для вас (а не для актеров).
Однако, если у вас есть более сложная система, которая включает в себя зависимости и координацию общего состояния, то актерский подход может помочь. В частности, с использованием участников и семантики передачи сообщений вы часто можете избегать использования явных блокировок для защиты общего состояния, фактически создавая копии этого состояния (сообщений) и реагируя на них.
Вы можете сделать это довольно легко с классическими проблемами синхронизации, такими как обеденные философы и проблема спальных парикмахеров. Но вы также можете использовать "актер", чтобы помочь с более современными узорами, т.е. Ваш фасад может быть актером, ваш модельный вид и контроллер также могут быть актерами, которые общаются друг с другом.
Еще одна вещь, которую я наблюдал, состоит в том, что актерская семантика изучается большинством разработчиков и "безопаснее", чем их заблокированные копии. Это связано с тем, что они повышают уровень абстракции и позволяют сосредоточиться на координации доступа к этим данным, а не защищать все обращения к данным с помощью блокировок. В качестве примера предположим, что у вас есть простой класс с членом данных. Если вы решите поместить блокировку в этом классе для защиты доступа к этому члену данных, тогда любые методы этого класса должны будут обеспечить доступ к этому элементу данных под блокировкой. Это становится особенно проблематичным, когда другие (или вы) модифицируете класс на более поздний срок, они должны помнить, что использовать эту блокировку.
С другой стороны, если этот класс становится актером, а член данных становится буфером или портом, с которым вы обмениваетесь сообщениями, вам не нужно забывать об этом, потому что семантика встроена в буфер, и вы будете очень четко знать, собираетесь ли вы блокировать это на основе типа буфера.
-Rick
Использование Актера является "естественным" по крайней мере в двух случаях:
Например, если вы обрабатываете сложные данные, используя серию фильтров, легко использовать конвейер актеров, где каждый актер получает данные от восходящего актора и устанавливает данные для нисходящего актера.
Конечно, этот поток данных не должен быть линейным, и если в вашем конвейере медленный шаг, вы можете использовать пул актеров, выполняющих ту же работу. Другим способом решения проблем балансировки нагрузки было бы использовать вместо этого подход, ориентированный на спрос, организованный с помощью своего рода виртуальной системы Kanban.
Конечно, вам понадобится синхронизация между актерами практически во всех интересных случаях, но вопреки классическому многопоточному подходу эта синхронизация действительно "конкретна". Вы можете представить себе ребята в factory, представьте себе возможные проблемы (у рабочих заканчивается работа, операции над потоком слишком быстрые, а промежуточным продуктам требуется огромное место для хранения и т.д.). По аналогии вы можете легко найти решение.
Действующие лица асинхронны и параллельны, но не гарантируют порядок сообщений или ограничение по времени относительно того, когда на сообщение можно воздействовать. Следовательно, атомарные транзакции не могут быть разделены на актеров.
Если в приложении/задаче нет изменяемого состояния, то актеры излишни, так как структуры акторов идут на все, чтобы избежать условий гонки.