For the JVM there are a number of STM solutions around today. Multiverse for Java (JVM languages actually) and Akka (which uses Multiverse) for Scala; plus numerous others.
STM seems to be a simpler model for writing concurrent software that solves a large range of problems. Having a simpler way to write a solution for a problem is a good idea, but is it really faster than lock-based solutions we are use to using? Also, what are the hidden issues with this approach?
The STM approach seems to work well for systems that are likely to read and update different objects in different threads.
STM needs to operate like serializable transaction isolation. The transactions appear to operate as if they were running serially. That is, if any value read or written during the transaction is changed by another transaction commit, then the transaction should fail.
Issues
- One issue that is important to consider is that your STM system may give you access to the latest committed values. If a commit occurs during processing and a value you have already read has changed, then eventually your transaction will fail; as you expect. But before it fails, you are processing inconsistent data and that can lead to inconsistent behavior of your program, including throwing exceptions.
- Doing anything inside a transaction must be able to be rolled back. So writing to a file, log or screen are not good to do inside a transaction that ultimately fails.
- Every thread reading a common value which changes with each update will cause most parallel transactions to fail.
