Proposal: replace readMVar with atomicReadMVar, breaking BC

[Tom Murphy]

Is there a reason why as I programmer I should prefer the non-FIFO
semantics, or is it implemented that way for efficiency?

Tom


El Jul 10, 2013, a las 5:20, "Edward Z. Yang" <ezyang at MIT.EDU> escribió:

> GHC HEAD recently got a new primitive: atomicReadMVar#, which allows you
> to read MVars without first taking and then putting back (removing a
> nasty race where readMVar only works properly when there are no waiting
> putters).
>
> atomicReadMVar behaves differently from readMVar.  The key
> differences are:
>
>    - An atomicReadMVar op never causes an MVar to become "empty" at any point.
>      This means less programs deadlock now.
>
>    - An blocked atomicReadMVar is always served by the *first* putMVar
>      to arrive (it cuts to the head of the queue), whereas readMVar
>      obeyed the FIFO ordering.  This means this program behaves differently:
>
>        m <- newEmptyMVar
>        forkIO $ takeMVar m
>        threadDelay 100
>        forkIO $ print =<< readMVar m {- atomicReadMVar m -}
>        threadDelay 100
>        putMVar m 1
>        putMVar m 2
>        -- readMVar: outputs 2
>        -- atomicReadMVar: outputs 1
>
>      It actually would not be too difficult to add support for atomicReadMVar
>      which *does* respect the FIFO ordering but I don't have a sense when
>      that would be useful.
>
> The general feeling Simon and I have is that everyone really wanted
> to make believe readMVar was atomicReadMVar, and so maybe we should
> break BC and make readMVar do the right thing.  But it is probably
> worth some discussion, and I entreat you to think about the second
> point more carefully.
>
> Thanks,
> Edward
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries