© 2020 Strange Loop
The last decade the speed of CPU's has been stagnating because of the inability to dissipate the heat and run them cost efficiently. The number of cores has been increasing steadily to compensate. 10 Years ago having access to a 48-core machine, most developer would consider unimaginable, but for $6000 you can order one on the Dell site today. So multi-core machines are here to stay.
Since more threads are needed to use all these cores, which is a problem in its own, the need to deal with concurrency control, is increasing as well. Traditionally this was the area of locks, semaphores and compare-and-swap instructions. And although they are extremely useful and probably will be for a long time to come, creating larger systems based on these lower concurrency primitives is a very daunting and error-prone task. I guess some of us have had the pleasure of running into race-problems and deadlocks and know how difficult it is to reproduce them.
Software Transactional Memory is a concurrency control mechanism that relies on a higher abstraction and tries to solves a lot of the traditional problems by treating the memory as a database where composition, isolation, consistency and atomicity are provided out of the box. During this presentation the general concepts behind STM are explained as well as some of the fundamental implementation difficulties. And an attempt is made the answer the question of STM is the silver bullet or just a tool in the toolbox.
Peter Veentjer has spend the last 5 years specializing on concurrency control. 2.5 Years he started with the "Multiverse":http://multiverse.codehaus.org Software Transactional Memory implementation, which is part of Akka/Typesafe-stack. And recently has joined "Typesafe":http://typesafe.com to work full-time on various concurrent and distributed improvements in the "Akka":http://typesafe.com/technology/akka project.