4 ms·

I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semapho

I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors. Like, show me the producer-consumer pattern using actors.

zzzcpan 8y ago
> I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors. Really, it's not obvious? Of course you can: instead of shared memory you now have each actor having its own memory, instead of using locks and working on shared memory you now have messages and can ask actors to do something with their memory and send you the result back.
mruts 8y ago
I mean, that's a pretty standard actor pattern.. https://github.com/foobatman/producer-consumer-akka-actor/tree/master/src/main/scala/com/intution/ai/actor https://github.com/foobatman/producer-consumer-akka-actor/tr... There are many more examples out there. Anything that a multi-threaded program can do, an actor can do.. I just think that actors are inherently more complex than threads for simple problems. For complex problems, I think actor are probably a better choice. A good example of a simple program is managing multiple TCP connections. At least in my (somewhat limited) experience with actors, polling TCP file descriptors is easier to manage creating an actor for each one.
conradfr 8y ago
Does this satisfy you ? https://github.com/elixir-lang/gen_stage https://github.com/elixir-lang/gen_stage
b3orn 8y ago
You just have to think a bit differently about your synchronization primitves. You don't have locks, you have a message queue and that is your synchronization primitive. A resource that should only be accessed by one thread is abstracted away using an actor, and the queue guarantees that only one process at the time has access, as the actor can only process one message at a time. You can implement locks using actors if you really want to. An actor represents the state of the lock and stores which actor locked it and only responds to the unlock message from that actor and ignores all lock and unlock messages from all the other actors until it is unlocked.

zzzcpan 8y ago

> I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors. Really, it's not obvious? Of course you can: instead of shared memory you now have each actor having its own memory, instead of using locks and working on shared memory you now have messages and can ask actors to do something with their memory and send you the result back.

mruts 8y ago

I mean, that's a pretty standard actor pattern.. https://github.com/foobatman/producer-consumer-akka-actor/tree/master/src/main/scala/com/intution/ai/actor https://github.com/foobatman/producer-consumer-akka-actor/tr... There are many more examples out there. Anything that a multi-threaded program can do, an actor can do.. I just think that actors are inherently more complex than threads for simple problems. For complex problems, I think actor are probably a better choice. A good example of a simple program is managing multiple TCP connections. At least in my (somewhat limited) experience with actors, polling TCP file descriptors is easier to manage creating an actor for each one.

conradfr 8y ago

Does this satisfy you ? https://github.com/elixir-lang/gen_stage https://github.com/elixir-lang/gen_stage

b3orn 8y ago

You just have to think a bit differently about your synchronization primitves. You don't have locks, you have a message queue and that is your synchronization primitive. A resource that should only be accessed by one thread is abstracted away using an actor, and the queue guarantees that only one process at the time has access, as the actor can only process one message at a time. You can implement locks using actors if you really want to. An actor represents the state of the lock and stores which actor locked it and only responds to the unlock message from that actor and ignores all lock and unlock messages from all the other actors until it is unlocked.