Proposal: replace readMVar with atomicReadMVar, breaking BC

[Edward Z. Yang]

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