No atomic read on MVar?
Philip K.F. Hölzenspies
p.k.f.holzenspies at utwente.nl
Thu Nov 6 13:09:39 EST 2008
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
More information about the Glasgow-haskell-users
mailing list