Когда следует использовать модель актера?

Question

Когда следует использовать модель актера ?

Это, безусловно, не гарантирует отсутствие тупиков.

Актер A может ждать сообщения от B, пока B ожидает A.

Кроме того, если субъект должен убедиться, что его сообщение было обработано, прежде чем перейти к следующему заданию, он должен будет отправить сообщение и дождаться сообщения «Ваше сообщение обработано» вместо прямой блокировки.

В чем сила модели?

Answer 1

Учитывая некоторую проблему параллелизма, что бы вы искали, чтобы решить, использовать ли актеров или нет?

Сначала я хотел бы определить проблему ... является ли основная мотивация ускорением вложенного цикла или рекурсии? Если так, то простой подход, основанный на задачах или подходе с параллельным циклом, вероятно, будет работать хорошо для вас (а не для участников).

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

Вы можете сделать это довольно легко с классическими проблемами синхронизации, такими как обедающие философы и проблема спящих парикмахеров. Но вы также можете использовать «актер», чтобы помочь с более современными шаблонами, то есть ваш фасад может быть актером, ваш вид модели и контроллер также могут быть актерами, которые общаются друг с другом.

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

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

-Rick

Answer 2

Использование Actor является «естественным» как минимум в двух случаях:

1. Когда вы можете разбить вашу проблему на набор независимых задач.
2. Когда вы можете разбить свою проблему на набор задач, связанных четким потоком операций (т. Е. программирование потока данных ).

Например, если вы обрабатываете сложные данные, используя серию фильтров, легко использовать конвейер участников, где каждый субъект получает данные от вышестоящего субъекта и устанавливает данные для нижестоящего субъекта.

Конечно, этот поток данных не должен быть линейным, и если шаг в вашем конвейере медленный, вы можете использовать вместо этого пул актеров, выполняющих ту же работу. Другим способом решения проблем балансировки нагрузки было бы использование подхода, основанного на спросе, организованного с помощью своего рода виртуальной Kanban системы.

Конечно, вам потребуется синхронизация между актерами почти во всех интересных случаях, но в отличие от классического многопоточного подхода, эта синхронизация действительно "конкретна". Вы можете вообразить парней на фабрике, представить возможные проблемы (у рабочих не хватает работы, операции на начальном этапе выполняются слишком быстро, а промежуточным продуктам требуется огромное место для хранения и т. Д.) По аналогии вы можете найти решение более легко.

Answer 3

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

Если в приложении / задаче нет изменяемого состояния, тогда актеры излишни, так как платформы акторов идут на все, чтобы избежать условий гонки.