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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
