In Multiverse there are a lot of parameters that can activate certain functionality on the transaction. Parameters like:
- automaticReadTracking (needed for blocking operations)
Each additional feature causes overhead on the STM because it takes longer to process a transaction and it also leads to increased memory usage. In Multiverse 0.4 I already added some learning functionality to the STM runtime that makes speculative choices and adapts if a choice didn’t work out well. I use this for selecting a good performing transaction implementation; based on how many reads/writes the transaction encountered the previous time the system is able to select a better fitting transaction next time.
There is no reason why not to inference optimal settings; just start with readonly and no automatic readtracking. If an update is done, the system knows that next time an update transaction is needed. The same goes for a retry; it a retry is done and automaticReadTracking is not enabled, the next transaction can run with this feature enabled. Perhaps similar techniques could be used to determine if readtracking is useful because a transaction runs often in read conflicts.
David Dice already wrote about this in his famous TL2 paper and I certainly think that it is going to save developers a lot of time. And if someone wants to fiddle with settings themselves, they can always override settings (or perhaps even deactivating the learning system). This is certainly something I want to integrate in one of the next Multiverse releases.