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