[Haskell-cafe] Implementing tryReadMVar
Jan-Willem Maessen - Sun Labs East
Janwillem.Maessen at Sun.COM
Wed Sep 1 13:09:44 EDT 2004
Einar Karttunen wrote:
> There are several cases in which multiple threads racing putMVar is
> correct. Consider e.g. a server thread encapsulating state, which
> needs to rate limit its clients. The server is put behind a MVar
> to which all the clients putMVar and thus block until the server
> is ready
> ...
> The server thread uses tryTakeMVar for its job.
>
> Now add a debug function:
>
> debug :: MVar SCoreT -> IO ()
> debug mv = tryReadMVar mv >>= maybe (putStrLn "Nothing") print
>
> And suddenly we have a created a subtle bug in the code with
> flawed tryReadMVar implementation.
Indeed, but depending upon the vagaries of scheduling, you may in fact
be guaranteed *never* to see any output (eg, when tryTakeMVar yields
on empty and putMVar yields unconditionally).
I was, however, curious what use you had in mind where writes were
racing, but where you nonetheless wanted to perform blind non-blocking
reads. Such situations are generally fraught with peril. In this
case, the peril is starvation of the debug thread---which you may or
may not actually care about.
-Jan-Willem Maessen
More information about the Haskell-Cafe
mailing list