4 ms·

This will become even more relevant as core counts above 32 become common place. Sadly most programmers have a hard time dealing with more than 1 thread. I ag

by rpledge 17y ago

This will become even more relevant as core counts above 32 become common place. Sadly most programmers have a hard time dealing with more than 1 thread. I agree a new paradigm is needed to solve this problem.

Aegean 17y ago
One good way to tackle is to use threads for hiding shared data. In a nutshell, instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate. The result is easy, deterministic concurrency, and many cores may be used this way. One of the founding goals of the Go language is also based on this idea.
- bad_user 17y ago
  > instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate That's not enough. If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)? Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results. Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).
wheaties 17y ago
Thankfully people are pushing through STM and actor based parallelism. There's already an STM for Boost, Clojure, Erlang, and Scala to name a few.
- jshen 17y ago
  will there be an issue with stm when core counts get large enough that there are a lot of failed transactions? I'm not well read on stm, but intuitively this would seem to be an issue.
- dkersten 17y ago
  And dataflow - a little bit, at least.
- 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.

by rpledge 17y ago

Aegean 17y ago

One good way to tackle is to use threads for hiding shared data. In a nutshell, instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate. The result is easy, deterministic concurrency, and many cores may be used this way. One of the founding goals of the Go language is also based on this idea.

bad_user 17y ago
> instead of sharing variables between threads and protecting them by a lock, each thread has access to a portion of data, and they synchronously communicate That's not enough. If we are to believe Intel that we'll have processors with thousands of cores, then you have a new problem ... how are you going to keep all those cores busy (regardless of the actual number, from 32 to 20000)? Another problem would be that you also want it to scale horizontally ... there's no reason why you'd want to know if another thread runs in the same process or on some other machine in China. All you care about is that you can spawn it, send a message to it and get some results. Multiple techniques for concurrency will develop in parallel (which is a PITA since devs will need to have a lot of experience to choose), although I'm pretty sure that STM will be the most popular technique (although the handling of concurrency shouldn't be limited just to controlling access to RAM).

wheaties 17y ago

Thankfully people are pushing through STM and actor based parallelism. There's already an STM for Boost, Clojure, Erlang, and Scala to name a few.

jshen 17y ago
will there be an issue with stm when core counts get large enough that there are a lot of failed transactions? I'm not well read on stm, but intuitively this would seem to be an issue.
dkersten 17y ago
And dataflow - a little bit, at least.
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.