[Haskell-cafe] Re: Stronger STM primitives needed? Or am I just
doing it wrong?
apfelmus at quantentunnel.de
Thu Apr 24 07:02:35 EDT 2008
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
> (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
More information about the Haskell-Cafe