Threads share memory so it’s natural to use shared memory for communication between threads. However, the problems it leads to, such as data races, mean shared memory must be synchronised. In turn, this has led programmers to try to create locking protocols that eliminate races without introducing deadlocks.
One of the posited solutions is to share memory without using locks by adopting a paradigm called Software Transactional Memory (PDF) (STM). It has been implemented in Haskell successfully but implementations in other languages have not been as quite as fruitful. This is mostly because of problems with performance, isolation and I/O. I’ve touched on STM in previous posts and mentioned why Microsoft discontinued its STM experiment because it could not see ‘STM playing a role in the killer concurrency apps for the next five years.’
That said, STM offers ease of use and reliability. STM shared memory is accessed within ‘atomic’ blocks and all code within these atomic blocks is executed as if there were no other threads, so there is no need for locking.
Yesterday I was reading a post that elaborates on STM and focuses on how it works. For example, it provides a ‘nutshell’ view of STM by analysing a simple singleton pattern in C++, points out that the code doesn’t work well in a multithreaded environment, considers why, and then suggests how a programmer can figure out a way of making the code sequence read-validation/final-write atomic.
It acknowledges that the approach might be considered ‘crazy’ but points out that it can be made universal, compiled into the language runtime, and may be implemented once and for all and used whenever concurrent access is needed.
The post also offers insight into one particular implementation aspect of STM that has been widely accepted: Transactional Locking II (PDF) (TL2).
The benefit of this description of STM is that it’s written in a very accessible manner, with coding examples, which developers will understand. The author explains that STM has the potential to replace locking with an easy-to-use, almost foolproof, scalable paradigm for concurrent access.
I’m not sure whether STM will take off. Perhaps this is dependent on the development of new concurrent languages. However, given that hand-crafted, hand-debugged concurrent solutions are both time and cost-intensive it’s an alternative that is well worth exploring. But equally, there are those in an opposing camp who claim that optimising locks is the way forward. I covered this in a previous posting.
I’d be really keen to hear from anyone who has STM experience. It could well be valuable for the Softtalk blog audience and perhaps we could use it in a blog post. So don’t be shy, leave a comment…