I said:
In that case, we can treat subatomic as a "hint" to the STM runtime. It could have a simpler type, and the semantics of "id":
subatomic :: STM a -> STM a
If the subatomic transaction turns out to be read-only, then we get the benefit of all four cases Ryan describes above. If it turns out to be read-write, we only get the benefit of cases 2 to 4, while case 1 must restart. It doesn't matter if the subatomic transaction captures variables which depend on previous reads, since changes to those reads would cause a restart regardless of the outcome of the subatomic transaction.
Scrap that. I realise now that it allows leakage of information read from variables. It would need to be: subatomic :: STM a -> STM () Which means it's no longer just a hint.