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:[EMAIL PROTECTED] 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 > _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe