Ryan Ingram wrote:
No spooky-action-at-a-distance is possible. David's more general "subatomically" primitive would achieve the same results; the proof is that (1) no side effects can be caused by the subatomic action, that is, no writes happen which could change future reads. (2) the result of the computation is ignored -except- for whether it retries or returns, that is, it can't affect the control flow of the rest of the transaction.
So, if have a transaction T that is waiting inside "retry" for a variable that it read to change, and a variable that is only accessed in a "subatomic" part of T is changed, we can try running the subatomic computation first. Here are the four cases:
1) The subatomic computation succeeded before and still succeeded. Then we know the end result of the computation is unaffected, and will still retry. No need to do anything. 2) The subatomic computation succeeded before and now fails (calls 'retry' or retryRO'). Then we know that the computation will now fail at this earlier point. Mark the change to "fail" in the transaction log and leave the computation in the "waiting for retry" state. 3) The subatomic computation failed before and still fails. See (1) 4) The subatomic computation failed before and now succeeds. The result of the entire computation can change, we should now re-run the entire computation.
Sounds good. But I wonder what "obscure" optimization comes next; can we have a toy-model of STM? I mean, it should be possible to express both the "continuation-logging" and "read-only-fail" optimization in terms of type STM a = Maybe a or similar? Regards, apfelmus