atomic MVar overwrite (was RE: [Haskell-cafe] How to use QSem?)

[S. Alexander Jacobson]

Basically, what I want is a tryReadSampleVar
function.

Or, if we stick with MVars, I don't want another
thread to operate between the tryTakeMVar and the
putMVar.  In particular, I don't want another
thread to believe (mistakenly) that the mvar is
empty when it is simply being updated.

I suppose I could define a new abstraction where I
have a second mvar that acts as an exclusive lock
on the the first MVar.  e.g.

   data XMVar a = XMVar (MVar ()) MVar a

   overWriteXMVar (XMVar lock mvar) val =
	withMVar lock (\_->tryTakeMVar mvar >> putMVar mvar val)
   tryTakeXMVar (XMVar lock mvar) val =
	withMVar lock (\_->tryTakeMVar mvar)

But, I think it would be more sane simply to
have a tryReadSampleVar somewhere.

-Alex-

_________________________________________________________________
S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com

On Wed, 23 Jun 2004, Simon Marlow wrote:

> On 23 June 2004 17:13, S. Alexander Jacobson wrote:
>
> > Ah, that worked.  Thank you. The MVar
> > documentation is also very brief.
> >
> > I would also like to overwrite the contents of an
> > MVar atomically regardless of whether it is full
> > or empty.  I am current using.
> >
> >   overWrite mvar val = tryTakeMVar mvar >> putMVar mvar val
> >
> > But it is not atomic :-(  The lib functions
> > (modifyMVar and tryPutMVar) are atomic but seem to
> > require that you know in advance the MVar's state.
>
> The question to ask here is "atomic with respect to what?".  modifyMVar
> is atomic only with respect to other threads performing modifyMVar-type
> operations on the MVar (i.e. take followed by put).  If another thread
> is doing repeated puts into the MVar, then modifyMVar's atomicity is
> defeated.
>
> There isn't really a problem here, you just need to be sure that you use
> your MVars in a consistent way - you can always define a new abstraction
> that doesn't permit operations to be performed in the wrong order.
>
> So in order to tell you how to write your overWrite function, we need to
> know what other operations are being concurrently performed on the MVar,
> and what invariants you expect to hold.
>
> Cheers,
> 	Simon
>