3 ms·

I'm really not sure Actors are the silver bullet. I write telcom software, and its just as easy to get a deadlock (ok maybe a little harder) using Actors than

by runT1ME 17y ago

I'm really not sure Actors are the silver bullet. I write telcom software, and its just as easy to get a deadlock (ok maybe a little harder) using Actors than traditional locking.

dkersten 17y ago
I also write (or wrote, up until recently) telecom software and, while I like Actors (certainly compared to monitor-based concurrency), I agree that they aren't really the silver bullet. I spend a lot of time thinking about concurrency and I've come to the conclusion that the dificulties of concurrency all come from the fact that everythings manual - the programmer has to carefully think about how everything fits together, or risk all kinds of problems: deadlock, inconsistent data, bad parallelism etc. The Actor model certainly makes things easier, but doesn't work as well for some problems. Its also still a manual task. STM improves monitor-based systems by alleviating the task of carefully placing locks around critical sections of code, but you must still determine where to place the transactions and this can still be a big task. So far, the only model that, IMHO, lends itself to implicit programmer-free concurrency is dataflow. Ultimately, I think we need a language that exposes all three models (monitor, actor, dataflow) as language primitives, handling it implicitly and transparently where possible.
- runT1ME 17y ago
  Interesting, I haven't gotten to hear the thoughts of too many other telecom engineers when it comes to next generation languages and threading. I'm pretty convinced it has to be one of the hardest problems to get right. Speaking of STM and locks, have you seen this epic debate? http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.html http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.h... The problem with telecom software (that I'm dealing with now, in my very humble opinion), and the reason it hurts my head, is because you're essentially dealing with a distributed system, each leg being a node (since each action a leg takes needs to go out over the wire). Not only do you need to see consistent 'state', you also need to make sure your actions are handled correctly as well.
  - dkersten 17y ago
    Ugh, tell me about it.. worse still if the nodes aren't all on fast connections. One thing we had to deal with is where a mobile operator had two sites with multiple nodes per site. Our nodes were connected through a high speed network on each site, but the connection between the two sites was very slow and unreliable, so we had to change our software so that it would "prefer" to communicate with other nodes on the same site before trying the second site.

by runT1ME 17y ago

I'm really not sure Actors are the silver bullet. I write telcom software, and its just as easy to get a deadlock (ok maybe a little harder) using Actors than traditional locking.

dkersten 17y ago

I also write (or wrote, up until recently) telecom software and, while I like Actors (certainly compared to monitor-based concurrency), I agree that they aren't really the silver bullet. I spend a lot of time thinking about concurrency and I've come to the conclusion that the dificulties of concurrency all come from the fact that everythings manual - the programmer has to carefully think about how everything fits together, or risk all kinds of problems: deadlock, inconsistent data, bad parallelism etc. The Actor model certainly makes things easier, but doesn't work as well for some problems. Its also still a manual task. STM improves monitor-based systems by alleviating the task of carefully placing locks around critical sections of code, but you must still determine where to place the transactions and this can still be a big task. So far, the only model that, IMHO, lends itself to implicit programmer-free concurrency is dataflow. Ultimately, I think we need a language that exposes all three models (monitor, actor, dataflow) as language primitives, handling it implicitly and transparently where possible.

runT1ME 17y ago
Interesting, I haven't gotten to hear the thoughts of too many other telecom engineers when it comes to next generation languages and threading. I'm pretty convinced it has to be one of the hardest problems to get right. Speaking of STM and locks, have you seen this epic debate? http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.html http://blogs.azulsystems.com/cliff/2008/05/clojure-stms-vs.h... The problem with telecom software (that I'm dealing with now, in my very humble opinion), and the reason it hurts my head, is because you're essentially dealing with a distributed system, each leg being a node (since each action a leg takes needs to go out over the wire). Not only do you need to see consistent 'state', you also need to make sure your actions are handled correctly as well.
- dkersten 17y ago
  Ugh, tell me about it.. worse still if the nodes aren't all on fast connections. One thing we had to deal with is where a mobile operator had two sites with multiple nodes per site. Our nodes were connected through a high speed network on each site, but the connection between the two sites was very slow and unreliable, so we had to change our software so that it would "prefer" to communicate with other nodes on the same site before trying the second site.