Актерская разработка - вопросы реализации - PullRequest
1 голос
/ 26 ноября 2009

это мое первое сообщение здесь, и я рад присоединиться к этому сообществу.

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

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

Другими словами, мы больше не вызываем методы произвольно. Они отправлены в очередь для поздней обработки. Затем очередь гарантирует, что состояние объекта (var) не изменяется в одно и то же время, поскольку все сообщения сериализуются.

Я понимаю, что эту модель довольно просто реализовать (по крайней мере, экспериментальную), и, возможно, поэтому слишком сложно найти какие-либо технические детали.

Мой вопрос касается очередей. Это типичный случай нескольких производителей и одного потребителя, и я подозреваю, что они требуют какой-то синхронизации. Это правда? Было бы другое решение? Я слышал, что они могут быть реализованы как структуры без блокировки.

Я не совсем уверен в этом. Будем благодарны за любые комментарии.

Приятного дня приятели

Ответы [ 2 ]

1 голос
/ 08 декабря 2009

Несколько производителей и один потребитель - отличный сценарий для использования Актеров, и не требует никакой синхронизации. В Scala вы обычно не используете изменяемое состояние при работе с актерами. Вы просто отправляете копию всех данных, требующих обработки.

Вы можете узнать больше об актерах в Scala в разделе "Программирование Scala" , доступном онлайн бесплатно.

0 голосов
/ 30 ноября 2009

Если я правильно понял, агенты получали сообщения в почтовом ящике, который ведет себя как параллельная очередь. Так что вам не нужно заботиться об этом. Если вы хотите поиграть с почтовым ящиком напрямую, вы можете взглянуть на эту красивую статью из замечательной "Руководства Java-разработчика по Scala" .

...