The 0.3 release of the software transactional memory implementation Multiverse is almost complete. I already started with the 0.4 release and it will get the following transaction execution models:
- readonly transaction with tracking reads; useful blocking operations and also to prevent unwanted load failures once a read has been executed
- readonly transaction without readtracking (already available in the 0.3 release)
- update transaction without read tracking (reduces stress on the transaction), but it could be subject to writeskews and can’t be used for blocking operations
- update transaction with read tracking (already available in the 0.3 release). This is useful for blocking operations but also for detecting write-skew problems. In the 0.4 detection for writeskew detection will be configurable
The 0.4 release also is going to get a mechanism that selects the optimal transaction implementation based on the number of reads/writes done on a transaction.
- tiny: optimized for a single atomic object (completely optimized to reduce object creation as much as possible)
- bound length: optimized for a maximum number of atomic objects e.g. 10 (based on an array)
- unbound length: optimized for bigger transaction (based on a map)
I have created some prototypes the show a big performance improvement for tiny transactions (2 a 3 times faster than growing-transactions). And based on the transaction familyname (if annotations are used, family name will be inferred automatically), the system will select the optimal implementation. The systems starts with tiny transactions, and if an implementation wasn’t ‘big’ enough, the transaction is aborted and a ‘larger’ implementation (or different settings) are used for the following transaction. This is completely invisible to the programmer apart from having some transaction failures in the beginning. But since transactions are retried automatically, this shouldn’t be a big problem.
The following features are also planned (or already partially implemented) for the 0.4 release:
- Transactional primitives (IntRef, BooleanRef etc)
- Support for subclassing atomic objects.
- Preventing unwanted object creation in transactions (Tranlocal objects are only cloned for local usage when they are written, not when read)
- Support for 2 phase commit to make distributed transactions possible. This was requested by Jonas Boner of the Akka project that used Multiverse as the STM implementation.