[Haskell-cafe] STM semantics

[Paolino]

Thanks, atomicity is what I was missing in the STM semantics. Now it
is clear. The retry primitive is not saying
 "block here" and this can imply "no more pass here", which is
somewhat difficult to express with locks

paolino
2009/10/24 Matthew Brecknell <matthew at brecknell.net>:
> Hi Paolino,
>
> You wrote:
>> 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 ?
>
> This is correct behaviour.
>
> Remember, STM transactions execute atomically, so it doesn't make sense
> to think of a transaction as being blocked at a particular point in the
> code. A blocked transaction is just waiting for a state in which it can
> execute all at once. Calling "retry" is saying that this transaction is
> not yet ready to execute.
>
> As noted by Alberto, readTChan calls "retry" to indicate that it (and
> whatever transaction called it) cannot execute when the channel is
> empty.
>
> Putting it all together, you can see that your transaction will execute
> when (and only when) "r" contains True, or when "c" is not empty.
>
> Hope that helps,
> Matthew
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>