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

Jan-Willem Maessen jmaessen at alum.mit.edu
Wed Apr 23 13:43:17 EDT 2008

On Apr 23, 2008, at 12:13 PM, Ryan Ingram wrote:

> On Wed, Apr 23, 2008 at 7:54 AM, Tim Harris (RESEARCH)
> <tharris at microsoft.com> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list