Normally STM’s are very optimistic, conflicting modifying transactions are able to execute concurrently but only one of them is able commit in the end. In most cases this is desired behavior, but in some cases it can be quite annoying (e.g. when doing IO) and you want to prevent that a transaction is going to conflict and a lot of work is lost.
In Multiverse 0.7 multiple levels of pessimistic behavior are going to be added:
- automatic lock all writes. This means that if you want update a transactional object, the locks on that object is either acquired or fails immediately. This looks a lot like the behavior MVCC databases like Oracle/Postgresql provide, although with these databases it still is possible to have concurrent reads and writes. With the new beta stm in Multiverse, this will be much harder to realize because the central clock, where MVCC/TL2 based STM rely on, has been removed because it limits scalability
- automatic lock all reads (so also all writes because they need to be read before being written).
- lock an individual object on reading (like the oracle select for update) or on writing for fine grained control
These properties will be accessible by setting the correct properties on the transaction or by doing a specific call to the API. So in essence one is now able to program using locks, but without the traditional problems:
- Locks are still composable
- race problems are not possible because locks are released to soon. Locks will not be released until the end of the transaction.
- race problems are not possible because locks are acquired too late. The transaction just fails with a conflict when such a transaction wants to commit
- locks can’t be forgotten to be released: locks will still be managed by the transaction and will automatically be released when the transaction aborts/commits
- it is not possible to run into deadlocks since a transaction can’t wait indefinitely on acquiring a lock
Atm there will only be support for exclusive locks, but read/write locks are probably going to be added in the 0.8 release. Although I’m still thinking about a good mechanism to upgrade shared locks to exclusive locks.