Ok, by now we all know that Object Oriented programming is likely to go the way of Erlang, or at least inherit an Actor model of language level concurrency.
In fact, I’ve even got an object system that I’m planning to implement just to find out how well this style of concurrency works in an Object Oriented programming language. The design of the language is even more post-Self/Slate than Newspeak (although I believe that this language will just complement the Smalltalk family of languages in all honesty).
Well then, Haskell…Haskell is actually very interesting, in this case by being one of the very few to push the limits of locking methods for concurrency rather than using the larger granularity involved in processes and message passing (not by much, but its still something).
The problem is that its impossible to write locking code by hand that doesn’t have at least one race condition hiding away in the corner. Not the ones you’ve already tested for, but the ones that would cause transactions to restart…like multiple threads locking a few items and then deadlocking…or even just managing the code required to restart deadlocks…yeah…lol…
Haskell provides a novel approach (its actually pretty old now, but it’s really only just starting to catch on, outside of Haskell anyway)… Software Transactional Memory.
STM is sometimes used in other areas of computing (OODBs, et ceteral), but the real gem here is that the Haskell type system nicely compartmentalized the side effects involved into a clever transaction form, within our imperative outer program. This makes working with transactions very much like the database stuff, only we’re only working with individual variables, so no complex table lookups.
Anyway, enough of my rambling, check it out:
Programming in the Age of Concurrency Software Transactional Memory
And if you haven’t already, remember to look at Erlang too…after all concurrency isn’t going away, and there are only two ways to get it right!
– Lorenz