Reader Writer Lock using Actor Model in Akka

[neel choudhury]

I want to implement the famous reader writer model using actor model. We can have multiple reader reading but only one writer can write. Also when a writer writes no reader can read and vice versa.

To solve this problem i thought of using a superviser actor which maintains a set for reader actors and a queue for writer actors. Now a writer can be dequeued and start writing when the set for readers are empty. Also when the writer completes all reader actors from the set can start reading.

Can we have a better problem of solving this famous problem using actor model?

Also is this model better than the original reader writer problem soved using read or write locks?

[Guido Medina]

Trying to emulate a read/write lock with actors can be very difficult, maybe agents can do?

http://doc.akka.io/docs/akka/snapshot/java/agents.html

HTH,

Guido.

[Rafał Krzewski]

Are you sure you are approaching the problem from the best angle? Akka gives you a guarantee that the execution of actor code is single threaded, so each time a message is processed, the code has an "exclusive lock" on the actor's internal state (quotation marks because there is actually no lock involved, just smart thread scheduling). 

Does your writer need to exchange several messages with the target actor, and the messages from readers should not be processed over the duration of that conversation? In such case, you should be able to implement it with little effort using become [1] and Stash [2]. For extra style points, you can use FSM [3] :) Just watch out for unbounded mailboxes when using Stash! Stashing large number of messages may exhaust heap space.

Cheers,
Rafał

[1] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Become_Unbecome

[2] http://doc.akka.io/docs/akka/2.4.2/scala/actors.html#Stash

[3] http://doc.akka.io/docs/akka/2.4.2/scala/fsm.html

[Stephen McDonald]

On Friday, 18 March 2016 08:59:14 UTC+11, Rafał Krzewski wrote:

Are you sure you are approaching the problem from the best angle? Akka gives you a guarantee that the execution of actor code is single threaded, so each time a message is processed, the code has an "exclusive lock" on the actor's internal state (quotation marks because there is actually no lock involved, just smart thread scheduling). 

Does your writer need to exchange several messages with the target actor, and the messages from readers should not be processed over the duration of that conversation? In such case, you should be able to implement it with little effort using become [1] and Stash [2]. For extra style points, you can use FSM [3] :) Just watch out for unbounded mailboxes when using Stash! Stashing large number of messages may exhaust heap space.

Stash is perfect for this use case. We use it to implement write transactions in CurioDB (https://github.com/stephenmcd/curiodb)

- Each command an actor receives is read or write, and has its own transaction ID

- When a write command is received and there's no current transaction, we store the transaction ID as the current transaction

- When a write command is received and there is a current transaction ID, we stash the command

- Once the transaction is finished, remove the transaction ID, and unstash all previously stashed commands to be replayed

- Read commands can always read, no stash-base-lock needed

[Guido Medina]

Akka Agents do that exactly, you can read anytime while writes happen serially, of course Agents cannot benefit AFAIK from Akka Sharding functionality for example, hence making stash just like CurioDB does a better fit (if you need to redistribute these values)

Regards,

Guido.