[Haskell-cafe] STM semantics
Alberto G. Corona
agocorona at gmail.com
Sat Oct 24 07:34:25 EDT 2009
According with the philosophy of STM, readTChan does not block, but retries:
readTChan :: TChan a -> STM areadTChan (TChan read _write) = do
listhead <- readTVar read head <- readTVar listhead case head of
TNil -> *retry**** *TCons a tail -> do writeTVar read tail return a
This retry forces the execution of the whole atomic block, so it do readTVar
again, readTVar suppossedly "wait" without locking as well, until new data
is available. Because it is True, the atomic block terminates.
The readTVar behaviour is not clear form me, althoug it is convenient.
Otherwise any atomic block with readTVar and retries would loop
continuously.
So I think that this execution is convenient, if not correct
2009/10/24 Paolino <paolo.veronelli at gmail.com>
> I have a doubt that this code works like I want because actual STM
> implementation exposes its effects
>
> import Control.Concurrent
> import Control.Concurrent.STM
>
> main = do
> c <- atomically $ newTChan :: IO (TChan ())
> r <- atomically $ newTVar False
> forkIO $ do
> atomically $ do
> r0 <- readTVar r
> case r0 of
> True -> return ()
> False -> readTChan c
> myThreadId >>= killThread
> threadDelay 1000000
> atomically (writeTVar r True)
>
> The thread stops on readTChan, but exits when I change the TVar, which
> happens before the readTChan.
>
> Should I trust this is the correct STM behaviour , and will not change
> in different implementations ?
>
> thanks
>
> paolino
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091024/a6c3a6cb/attachment.html
More information about the Haskell-Cafe
mailing list