On Apr 23, 2008, at 12:13 PM, Ryan Ingram wrote:
On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH)
<[EMAIL PROTECTED]> wrote:
What do you think about a slight change:
readTVarWhen :: TVar a -> (a -> bool) -> STM a
This seems strictly less powerful than retryUntil:
readTVarWhen v p = retryUntil v p >> readTVar v
Consider the following transaction:
intV :: TVar Int
boolV :: TVar Bool
interesting = atomically $ do
retryUntil intV (> 50)
retryUntil boolV id
Lets say that intV contains 100 and boolV contains False. Then this
transaction retries. Now, if intV changes to 101, this transaction
doesn't need to re-run; we can see immediately that no predicate
changed.
How can we tell, though? In effect, I need to either say "I care when
intV changes" or I need read intV again and make sure that (> 50)
still holds before I can commit.
Using "readTVarWhen", this is less clear; the transaction
log would hold a read on intV which would be more difficult to ignore.
In order to guarantee that your test is atomic wrt the rest of the
transaction, you'll need to do the same. What you do in response to a
change in intV might be different, though.
I've been trying to decide whether either of these is implementable in
terms of `orElse`, in such a way that we immediately check the
predicate upon retry before doing anything else. I can't quite make
up my mind whether this is possible or not.
-Jan-Willem Maessen
-- ryan
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
