Актеры: Как эффективно обрабатывать данные, предназначенные для чтения

Question

Предположим, у меня есть актер с одним полем.99 из каждых 100 сообщений актеру читают значение, а сотое обновляет значение.В этом случае я хотел бы обрабатывать чтения параллельно.Другими словами, как я могу добиться производительности блокировок чтения / записи с использованием Actors?Это практично для стандартных актеров Scala или Akka?Или я упускаю суть актёров:)

Обновление: исправлен запутанный язык, извините

Answer 1

[Отказ от ответственности: я ПО Акки]

Я предлагаю использовать Агенты вместо этого, чтение может быть выполнено в любой момент, но только одна запись за раз.

http://doc.akkasource.org/agents-scala

РЕДАКТИРОВАТЬ: http://doc.akka.io/docs/akka/2.1.0/scala/agents.html (попробуйте эту ссылку)

Answer 2

Возможно, вы упускаете из виду актеров. Я предполагаю, что вам нужен актер, которому вы отправляете запрос, а затем он отправляет ответ. Для отправки актеру сообщения, его обработки и отправки ответа требуется немало механизмов. Фактическая генерация ответного сообщения будет создана как задача и отправлена ​​в пул потоков. Между очередью сообщений и пулом потоков есть несколько мест, которые требуют блокировок или, в лучшем случае, операций CAS. Обычно дело в том, что актер выполнит некоторую работу в отдельном потоке на основе этого сообщения.

Если вы просто хотите читать и редко записывать данные (например, увеличить счетчик или получить доступ к значению на карте), вам будет гораздо лучше использовать соответствующий класс из java.util.concurrent.

Answer 3

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

По сути, у каждого участника есть почтовый ящик, в который сообщения отправляются, а затем обрабатываются по одному. В вашем сценарии это было бы довольно расточительно. Как и предполагалось, использование чего-то из java.util.concurrent было бы наиболее эффективным.

Answer 4

Актеры предназначены для последовательной обработки сообщений. Это облегчает их рассуждение: вы получаете одно сообщение за раз, поэтому любые переменные в субъекте (если они не изменены кем-либо еще) могут быть изменены, не думая о параллелизме. Это самый эффективный метод? Точно нет! Но несколько неэффективный код, который работает правильно почти всегда лучше, чем высокоэффективный код, который нарушен .

То, о чем вы просите, прямо противоположно: вы хотите явно подумать о параллелизме («Я знаю, что 99% обращений будут считываться и, следовательно, могут происходить параллельно!»), Чтобы повысить скорость обработки. В этом случае вы, вероятно, захотите использовать java.util.concurrent.locks.ReentrantReadWriteLock для непосредственного управления доступом к изменяемой переменной (если тип доступа, найденный в java.util.concurrent.atomic._, не работает для вас). Просто помните, что теперь вы взяли на себя бремя правильной блокировки, и будьте осторожны.