[Haskell-cafe] Re: Stronger STM primitives needed? Or am I just doing it wrong?

[Matthew Brecknell]

Ryan Ingram said:
> 
> retryUntil :: TVar a -> (a -> Bool) -> STM ()
> 
> [...]
>
> the semantics would be that the transaction log,
> instead of saying "I read from v" would say "I read from v and failed
> because v didn't satisfy this predicate".
> 
> Changes to any other variable in the log would have the same effect as
> always: restarting the transaction.  This is actually required in my
> desired use case; I want to block until "now" becomes >= t, or a
> different TVar gets filled with a non-Nothing value.

I see now what you mean, and I can see that it might be a nice little
addition. By giving the STM runtime additional information about what
conditions would allow the transaction to progress, it might be able to
save some false retries. Note that the only work that is saved is the
work done to get to the retryUntil.

However, strictly speaking, the STM runtime doesn't need this additional
information. You could view a composite STM transaction as an inverted
tree, with individual reads at the leaves, merging through monadic
bindings towards the root, which is the final result (which includes the
transaction's atomic updates). A transaction waiting on a retry is just
one of these trees in suspended animation, waiting for a new value to be
written to one of the leaves. When such a value is written to one of the
leaves, only its downstream nodes need re-evaluation.

Implementing STM that way may not be worth the effort, though, whereas
retryUntil might be.