Proposal: replace readMVar with atomicReadMVar, breaking BC

[Simon Marlow]

On 10/07/13 13:45, Tom Murphy wrote:
> Is there a reason why as I programmer I should prefer the non-FIFO
> semantics, or is it implemented that way for efficiency?

You might prefer the FIFO semantics if you want to take advantage of the 
fact that the RTS implements a double-ended queue of threads in such a 
way that threads can be removed from the middle in O(1) time if they 
receive an exception from throwTo.  However, the only person I know that 
does this sort of thing is Chris Kuklewicz, and I can never understand 
his code. :-)

I expect the readMVar-jumps-to-the-front-of-the-queue semantics will be 
more useful in most cases.  We could have both, but I doubt it's worth it.

Cheers,
	Simon



> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>