Действующие лица (scala / akka): подразумевается ли, что доступ к методу приема будет осуществляться потокобезопасным способом?

#scala #thread-safety #akka #actor

#scala #потокобезопасность #akka #актер

Вопрос:

Я предполагаю, что сообщения будут приниматься и обрабатываться потокобезопасным способом. Тем не менее, я читал (некоторые) документы akka / scala, но я еще не встречал ключевое слово ‘threadsafe’.

Ответ №1:

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

Это также одна из причин, по которой Akka ввела концепцию ActorRef — дескриптора, который позволяет вам взаимодействовать с субъектом посредством передачи сообщений, но не путем прямого вызова его методов.

Комментарии:

1. Спасибо Przemek. Это объясняет.

Ответ №2:

Я думаю, у нас это довольно хорошо задокументировано: http://doc.akka.io/docs/akka/2.3.9/general/jmm.html

Комментарии:

1. Я прочитал этот документ несколько раз. Я новичок в JVM; в моем понимании, «происходит раньше» только подтверждает «видимость». У нас все еще могут возникнуть проблемы из-за нескольких потоков в критической секции.

2. Akka защищает от одновременного выполнения сообщений для одного и того же субъекта, позволяя только один раз запланировать выполнение почтового ящика. (либо он запланирован для выполнения, либо нет). Делая почтовый ящик работоспособным, мы не только избегаем выделения новых исполняемых файлов, но и можем с помощью простой операции CAS гарантировать, что почтовый ящик будет запланирован для выполнения только один раз, что означает, что не требуется дополнительная бухгалтерия, чтобы убедиться, что 2 потока не обрабатывают один и тот же почтовый ящик одновременно.время.

3. Потрясающее объяснение. Это, несомненно, поможет мне в дальнейшем чтении. Однако один вопрос: как я мог вывести «взаимоисключающую обработку» почтового ящика из akka.io/docs/akka/1.2/general/jmm.html ?

4. Актеры Akka не были бы актерами, если бы они разрешали многократное выполнение. 😉

Ответ №3:

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

Однако вы не должны подрывать AKKA, используя изменяемые сообщения или общедоступное состояние. Если вы разрабатываете свои действующие лица как автономные функциональные единицы, тогда они будут потокобезопасными.

См. Также: http://doc.akka.io/docs/akka/2.3.12/general/actors.html#State

и http://doc.akka.io/docs/akka/2.3.12/general/jmm.html для более глубокого изучения модели памяти AKKA и того, как она справляется с проблемами «протектора».