Объявление переменных состояния актора как изменчивых

Я довольно новичок в концепции Akka и концепциях параллелизма. И из документов Akka я понял, что только одно сообщение в почтовом ящике Actor будет обрабатываться одновременно. Таким образом, один поток будет обрабатывать состояние Актера за раз. И я сомневаюсь в том, что объявление переменной состояния/данных Actor как изменчивого - «Var» (только когда «Val» не подходит) не приведет к возникновению несогласованных состояний Actor в случае параллелизма. Я использую Scala для разработки. В следующем Мастер-актере детали рабочих хранятся в изменяемой переменной «Рабочие». Будет ли проблема с параллелизмом?Объявление переменных состояния актора как изменчивых

class Master extends PersistentActor with ActorLogging { 

    ... 
    private var workers = Map[String, WorkerState]() 
    ... 
    }

источник

2015-10-03 Sreenath Chothar

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

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

http://doc.akka.io/docs/akka/snapshot/general/actors.html

Кроме того, это хорошая вещь, которую вы используете var вместо val с изменяемой картой :)

источник

2015-10-03 05:29:05 lloydmeta

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

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

Другим способом рассмотреть кодирование ситуаций, как это должны изменить «состояние» актера после обработки каждого сообщения. Например .:

class Master extends PersistentActor with ActorLogging { 

    type MyStateType = ... // eg. Map[String, WorkerState], or an immutable case class - of course, feel free to just inline the type... 

    def receive = handle(initState) // eg. just inline a call to Map.empty 

    def handle(state: MyStateType): Actor.Receive = LoggingReceive { 

    case MyMessageType(data) => 

     ... // processing data - build new state 

     become(handle(newState)) 

    case ... // any other message types to be handled, etc. 

    } 

    ... // rest of class implementation 

}

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

источник

2015-10-03 07:46:16 Shadowlands

Объявление переменных состояния актора как изменчивых

ответ

Смежные вопросы