[ moving to glasgow-haskell-users@haskell.org ]
Conal Elliott wrote:
Thanks, Simon. If I understand the mechanism you're describing, it
discards readers of an empty MVar when there are no other references to
the MVar *because* the MVar can never get written. And if there are
other readers but no writers, then I'm guessing GC wouldn't know that,
and none of the readers get discarded. Is that so?
I'm not sure I understand precisely what you mean here. Do you mean when
there are other running threads that might read the MVar in the future? In
that case, yes, blocked readers would not be detected and sent an exception.
I think Baker & Hewitt's trick was analogous to discarding writers of an
already full MVar when there are readers (readMVar) but no takers
(takeMVar). (Though not quite, since readMVar is implemented via
takeMVar & putMVar.)
It shouldn't be the case that you have a thread doing putMVar on a full
MVar simultaneously with another thread doing readMVar, because the
readMVar could be preempted between the take and put and then block - this
would almost certainly be an undesirable race condition.
I guess that effectively means IVars instead of MVars.
In either direction (blocked reader or blocked writer), the interface of
MVars (or IVars) would seem to prevent an accurate analysis, since GC
wouldn't know whether a Var reference was for reading or writing.
>
Right? A simple solution might be to hide the Var itself and instead
expose reader and writer halves. If there's an analysis problem at all,
does that solution make sense?
Absolutely. It ought to be possible to implement this using weak pointers
in GHC, because you want relationships like "if a writer is alive, then the
readers are alive", and this is the kind of thing you can express with weak
pointers.
Cheers,
Simon
Cheers, - Conal
On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
GHC already garbage-collects threads that are blocked on an MVar
that is otherwise inaccessible (and hence cannot be updated). More
precisely, GHC sends the thread an asynchronous exception
(ThreadBlocked or something), so that it has a chance to clean up.
So perhaps the GC you want is already implemented?
Simon
*From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] *On Behalf Of *Conal Elliott
*Sent:* 24 December 2007 00:15
*To:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
*Subject:* [Haskell] garbage collection of Concurrent Haskell threads?
The classic paper "The Incremental Garbage Collection of Processes"
(http://citeseer.ist.psu.edu/baker77incremental.html) describes
"futures" and how particularly garbage collecting them when their
pending result is no longer referenced. I've been playing with an
implementation of futures in Concurrent Haskell (
http://haskell.org/haskellwiki/Reactive), using MVars, and I'm
stumped about how to GC non-winning threads in a race between
futures ("parallel or"). I'm having winner kill loser, which seems
to work fine, though is potentially dangerous w.r.t locked
resources. Still, the elegance of a GC-based solution appeals to
me. Has anyone explored process GC ideas for Concurrent Haskell (or
STM)?
Futures are implemented using Concurrent Haskell's MVars. I first
tried using STM and TVars, simply using orElse to implement mappend
for futures. However, I didn't see how to avoid nesting
"atomically", which yielded a run-time error. If anyone has ideas
about using STM & TVars for futures, I'd love to hear.
Thanks, - Conal
------------------------------------------------------------------------
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
