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
On Mon, Nov 3, 2008 at 23:51, David Menendez [EMAIL PROTECTED] wrote:
On Mon, Nov 3, 2008 at 6:29 AM, Philip K.F. Hölzenspies
[EMAIL PROTECTED] wrote:
I have now implemented my variable as a pair of MVars, one of which serves as
a lock on the other. Both for performance reasons and for
It is true that STM's TMVars (which are TVar (Maybe _)) allow atomic readTMVar.
They are not a great replacement for MVars for serious performance reasons.
MVars have wake one semantics: There can be many threads stopped and waiting
on a particular MVar to be filled/emptied. These are
Philip K.F. Hölzenspies wrote:
I ran face first into an assumption I had made on MVar operations (in
Control.Concurrent); I had assumed there to be an atomic read (i.e.
non-destructive read, as opposed to destructive consume/take). The following
program illustrates what I had in mind.
Dear GHCers,
I ran face first into an assumption I had made on MVar operations (in
Control.Concurrent); I had assumed there to be an atomic read (i.e.
non-destructive read, as opposed to destructive consume/take). The following
program illustrates what I had in mind.
testAtomic :: IO ()
On Mon, Nov 3, 2008 at 6:29 AM, Philip K.F. Hölzenspies
[EMAIL PROTECTED] wrote:
I have now implemented my variable as a pair of MVars, one of which serves as
a lock on the other. Both for performance reasons and for deadlock analysis,
I would really like an atomic read on MVars, though. Does
