4 ms·
I would say the most natural is STM - you don't need to change much, just wrap your concurrent, shared memory accessing code in a STM transaction, be careful wi
by pka 11y ago
I would say the most natural is STM - you don't need to change much, just wrap your concurrent, shared memory accessing code in a STM transaction, be careful with IO (or use a language which prohibits IO in a STM block like Haskell) and you are done.
Actors are pretty nice when it comes to distributed services, and Erlang/OTP is pretty much uncontested here.
Threads with manual locking are only useful when speed is really important, but this is somewhat of a moot point when it comes to concurrency. Both STM and Actors perform slower (starvation, message copying overhead).
Here [0] is a nice, in-depth discussion about some of the different approaches to concurrency.
[0] https://plus.google.com/109566665911385859313/posts/FAmNTExSLtz https://plus.google.com/109566665911385859313/posts/FAmNTExS...
- ignoramous 11y agoInteresting point there. Latency vs Throughput. Using green-threads (Quasar on JVM) might be the best of both worlds then? Akka.io on JVM could pretty much do what Erlang can on BEAM, functionality wise. Although some people have raised concerns over it being a "pseudo" solution and that it is a no match for Erlang.