Implement an atomic readMVar

[simonmar]

Requested by various people, most recently by John Launchbury.

The idea would be that readMVar is atomic, and never blocks if the MVar is full. A concurrent putMVar operation cannot intervene while readMVar is reading the value.

To implement this, we would need two kinds of blocked threads in the MVar queue, and putMVar would need to wake up zero or more readMVar operations followed by at most one takeMVar.

[ezyang]

Some relevant discussion here:

 http://www.mail-archive.com/haskell-cafe@haskell.org/msg04677.html  http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg15389.html  http://www.mail-archive.com/haskell-cafe@haskell.org/msg02127.html

[lpsmith]

There is another possible use case here; if GHC implemented both an atomic readMVar and tryReadMVar, then Control.Concurrent.Chan.isEmptyChan could be implemented in a thread-safe way.

Admittedly, this would require the receiving end of a Chan a to use an external semaphore by changing the MVar (Stream a) to a (IORef (Stream a), MVar ()) pair, so that the current read hole could be obtained without blocking. But the problem is that without atomic readMVars, there is a chance that isEmptyChan would observe the stream when another thread is in the process of reading from the thread, and thus say that the channel is empty when in fact it is not. Similarly, without an atomic tryReadMVar, there is the chance that isEmptyChan would observe the stream when another thread is in the process of calling isEmptyChan, and get a faulty empty result.