Ah yes, then you're doing a double handshaking in a sense, of course. Not
ideal if you just want to put something in the MVar and resume as quick as
possible. However, in that case one could fork a dummy thread that only does
readMVar I guess.
But does it also work when you want multiple threads that are waiting for
the same MVar, and a single thread that writes to the MVar? It think is
does, when you use readMVar one thread will get the value and the others
will get it sequentially since readMVar puts the value back...
Again you guys gave a solution, an amazing brain thank this cafe is...
Usually one gets drunk in a cafe, destroying braincells. Here it's the
opposite :)
On Fri, Feb 13, 2009 at 11:01 AM, Duncan Coutts wrote: On Thu, 2009-02-12 at 22:58 -0500, David Menendez wrote: On Thu, Feb 12, 2009 at 6:26 PM, Don Stewart bugfact: Consider the following code stamp v x = do
t <- getCurrentTime
putMVar v (x,t) Is it possible - with GHC - that a thread switch happens after the t
<-
getCurrentTime and the putMVar v (x,t)? Yes. if 't' is heap allocated, there could be a context switch. If so, how would it be possible to make sure that the operation of
reading the
current time and writing the pair to the MVar is an "atomic"
operation, in the
sense that no thread switch can happen between the two? Would this
require STM? Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or
a
modifyMVar in IO? As I understand it, withMVar or modifyMVar will protect you from
extraneous exceptions, but they won't prevent another thread from
writing to the MVar between the take and the put. You have to cooperate with the other users of the MVar. If each thread is using readMVar, withMVar or modifyMVar then it's fine.
The read/with/modify actions do a takeMVar followed by a putMVar. If one
thread is using withMVar and another is doing putMVar directly then the
exclusion scheme does not work. Duncan