[Haskell-cafe] Does the TMVar and TChan really obey STM rules?

Neil Brown nccb2 at kent.ac.uk
Thu Dec 24 11:45:47 EST 2009

Andrey Sisoyev wrote:
> Hi everyone,
>> isEmptyTMVar :: TMVar a -> STM Bool	Source
>> Check whether a given TMVar is empty.
>> Notice that the boolean value returned is just a snapshot 
>> of the state of the TMVar. By the time you get to react on its result, 
>> the TMVar may have been filled (or emptied) - so be extremely careful 
>> when using this operation. Use tryTakeTMVar instead if possible.
> When I read this in the haddock to Control.Concurrent.STM.TMVar, I started
> to suspect that the behavior of TMVar and TChan might be worse than I
> imagined. 
That warning seems a little paranoid to me.  The state of the TMVar must 
persist to the end of the transaction (from the point of view of the 
process executing a transaction), so isEmptyTMVar seems fine as long as 
you act on it in the same transaction.  What would be bad would be 
something like:

do b <- atomically $ isEmptyTMVar tv
     if b ....

Where you act on the value in a later transaction.  (Unless I've missed 
> Few questions on TMVar and TChan:
> (1) If 2 threads are sleeping-waiting for the output of TChan, and it gets
> filled, do they both wakeup, or just one? 
> (2) Similar question about reading/writing TMVar.
> (3) If a thread is sleeping-waiting for the output of TChan, but transaction
> wants to restart due to the change in any of touched TVar, then does the
> thread wakeup and restart the transaction?
> (4) Similar question about TMVar.
> Also, if there is some paper on this, please, give me a link on it.
I believe, 1 and 2: both wake up and retry the transaction, but only the 
process that completes the transaction first will succeed, the other 
will end up going back to sleep.  3 and 4: yes.  I think the rule is 
simply, if you call retry, you'll wait until any TVar you've read from 
so far changes, then you'll wake up and redo the transaction.  To see 
how that affects TMVar and TChan, read their source code to see what 
they are actually doing with TVars and retry.


More information about the Haskell-Cafe mailing list