On this blog, I’ve already discussed some of the challenges that come from having shared data in multicore programs. The most popular approach to solving these has been to use locks, which transfer control of the shared resource between different processes as required. While that can avert data races, the implementation of locks can cause problems of its own, including deadlock and livelock. I wrote more about locks last week.
An alternative approach is to use the Software Transaction Memory (STM) model, although Jeff Darcy notes that this also requires shared memory and requires great skill to implement without causing deadlock. He cites the old saying that a bad programmer can write Fortran in any language, and extends it to say bad programmers can create deadlock in any language.
I’d say that maybe it’s unfair to blame a model for the shortcomings of the coders who use it, although in an ideal world you’d have tools that were robust enough to make it quite difficult to introduce bugs. To be able to choose the right models, it is important that programmers understand the strengths and weaknesses of each one.
Darcy’s observation about STM was in a post he’s written about actors. I’ve seen quite a bit of buzz around this approach recently, and Jeff Darcy’s explanation of the actor model is one of the clearest. In brief, instead of transferring control over resources between processes, certain processes own control of the resources permanently. Any that want to, for example, modify a shared variable, will have to send a request to the owner of that variable. The theory is sound, although it will need to be implemented with care. At its heart, it serialises access to a shared resource, which could result in a bottleneck and ultimately a drop in performance.
For a more technical insight into actors, Bartosz Milewski has written an extensive overview that touches on examples from Erlang, Scala, C++ and D.
The actor model makes a valuable contribution to the programmer’s toolkit. The more models programmers have at their disposal, the easier it will be to solve the recurring challenges of multicore programming.
Filed under: Multicore, Programming Tagged: | actors, deadlock, livelock, locks, STM
[...] The language is still in its early stages of development – the latest build is 1.0.45, available for free download here. But the roadmap envisages a language that can be used to create multithreaded programs in Javascript, which could enable web applications to take advantage of multicore processing. The approach is based on actors, which I blogged about recently. [...]
[...] uses an approach based on agents and actors. Agents are chunks of code that pass asynchronous messages between each other, but never interact [...]
[...] segment, and then allowing others to communicate with that segment (an actor) using messaging. I covered actors previously here. The DZone article includes some examples of simple actor code based on GPars, using the actor() [...]