Когда следует использовать модель субъекта?
Это, конечно, не гарантирует отсутствие взаимоблокировок.
Актор А может ждать сообщения от Б, пока Б ждет А.
Кроме того, если актер должен убедиться, что его сообщение было обработано, прежде чем перейти к следующей задаче, ему придется отправить сообщение и дождаться сообщения «ваше сообщение было обработано» вместо прямой блокировки.
В чем сила модели?
Учитывая некоторую проблему параллелизма, что бы вы искали, чтобы решить, использовать ли актеров или нет?
Сначала я хотел бы определить проблему ... является ли основной мотивацией ускорение вложенного цикла for или рекурсии? Если это так, то простой подход, основанный на задачах, или подход с параллельным циклом, скорее всего, сработает для вас (а не для актеров).
Однако если у вас есть более сложная система, включающая зависимости и координацию общего состояния, вам может помочь акторный подход. В частности, благодаря использованию акторов и семантики передачи сообщений вы часто можете избежать использования явных блокировок для защиты общего состояния, фактически создавая копии этого состояния (сообщения) и реагируя на них.
Вы можете легко сделать это с помощью классических задач синхронизации, таких как проблема обедающих философов и проблема спящих парикмахеров. Но вы также можете использовать «актора», чтобы помочь с более современными шаблонами, т.е. ваш фасад может быть актором, ваше представление модели и контроллер также могут быть акторами, которые взаимодействуют друг с другом.
Еще одна вещь, которую я заметил, заключается в том, что семантика акторов доступна большинству разработчиков и «безопаснее», чем их заблокированные аналоги. Это связано с тем, что они повышают уровень абстракции и позволяют вам сосредоточиться на координации доступа к этим данным, а не на защите всех доступов к данным с помощью блокировок. В качестве примера представьте, что у вас есть простой класс с элементом данных. Если вы решите поместить блокировку в этот класс для защиты доступа к этому члену данных, то любые методы этого класса должны будут гарантировать, что они обращаются к этому элементу данных под блокировкой. Это становится особенно проблематичным, когда другие (или вы) изменяют класс позже, им приходится помнить, чтобы использовать эту блокировку.
С другой стороны, если этот класс становится актором, а член данных становится буфером или портом, с которым вы общаетесь через сообщения, вам не нужно помнить о блокировке, потому что семантика встроена в буфер, и вы будете очень явно знать собираетесь ли вы блокировать это в зависимости от типа буфера.
-Рик
Использование Актера «естественно» по крайней мере в двух случаях:
Например, если вы обрабатываете сложные данные с помощью серии фильтров, легко использовать конвейер акторов, где каждый актор получает данные от вышестоящего актора и передает данные нижестоящему актору.
Конечно, этот поток данных не должен быть линейным, и если какой-то шаг в вашем конвейере идет медленно, вместо этого вы можете использовать пул актеров, выполняющих ту же работу. Другим способом решения проблем с балансировкой нагрузки может быть использование подхода, основанного на спросе, организованного с помощью своего рода виртуального Система Канбан.
Конечно, вам понадобится синхронизация между акторами почти во всех интересных случаях, но в отличие от классического многопоточного подхода, эта синхронизация действительно «конкретна». Вы можете представить себе парней на фабрике, представить возможные проблемы (рабочим не хватает работы, операции вверх по течению выполняются слишком быстро, а промежуточным продуктам требуется огромное место для хранения и т. д.). По аналогии вы сможете легче найти решение.
Я не эксперт по акторам, но вот мои 2 цента, когда использовать акторную модель: акторная модель не подходит для каждого параллельного приложения, например, если вы создаете приложение, которое является многопоточным и работает с высокой степенью параллелизма. для решения проблемы параллелизма. Актеры действительно вступают в игру, когда вы создаете приложение, управляемое событиями. Например, у вас есть приложение, и вы отслеживаете, что пользователи нажимают в вашем приложении в режиме реального времени. Вы можете использовать акторов для выполнения действий в реальном времени, разделенных по пользователям, устройствам или любым другим требованиям вашего бизнеса, поскольку акторы сохраняют состояние. Так, например, если некоторые пользователи лежат в акторах, которые кликнули на shirts, вы можете отправить им уведомление о каком-то купоне. Также некоторые приложения, в которых могут пригодиться актеры: финансы (ценообразование, обнаружение мошенничества), многопользовательские игры.
Субъекты являются асинхронными и параллельными, но не гарантируют порядок сообщений или ограничение времени, когда сообщение может быть обработано. Следовательно, атомарные транзакции не могут быть разделены на акторы.
Если приложение/задача не включает в себя изменяемое состояние, то Актеры являются излишними, поскольку фреймворки Актеров делают все возможное, чтобы избежать условий гонки.
