No atomic read on MVar?

[Philip K.F. Hölzenspies]

L.S.,

First off, obviously, many thanks for all these usefull replies. A special 
thanks to Chris. Your e-mail was very insightfull and instructive. I did, in 
the end, decide to do my own queuing and scheduling using MVar () signaling, 
guarding MVar a things. I want to avoid IORefs, because for my application, I 
will later try to move on to distributed memory. Using MVars (or variations 
thereof, but at least variables with mutexed inter-thread behaviour) should 
help me when I start distributing threads over processors with segmented 
memories.

Considering that I'm not very well versed in cmm, I can not fully appreciate 
the implementation impact of having atomic reads. They just seem intuitive. I 
see them somewhat like the isEmptyMVar, but I see there is a difficulty due 
to blocking. Essentially, instead of having one single suspended-readers 
queue - as is currently the case, from what I've understood - there could be 
a queue for readers (non-destructive and atomic) and for takers 
(destructive). Whenever something is putMVar'ed into an empty MVar, the read 
queue is processed first (all waiting threads are handed the newly produced 
value and woken up), after which the first of the take-queue is woken up and 
given the value, leaving the MVar empty again.

When discussing efficiency in the context of this suggestion, please also 
consider the memory and concurrency sides of things. Surely, there will be 
more concurrency (more threads are woken up, because readMVars are queued 
with higher priority and always awoken), but I have a lingering suspicion 
that there may also be more sharing (because readMVars are clumped together). 
I would have to see profiling data on this sharing business, but I imagine 
quite a few cases where "a value" is good enough and it need not necessarily 
be "the value that should be in the MVar considering the exact order of 
arrival of threads at the mutex."

My two cents ;)

Regards,
Philip