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?
<br><br>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.) I guess that effectively means IVars instead of MVars.
<br><br>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?
<br><br>Cheers, - Conal<br><br><div class="gmail_quote">On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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. </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">So perhaps the GC you want is already implemented?<br>
<br>
Simon</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0cm 0cm;">
<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;">
<a href="mailto:haskell-bounces@haskell.org" target="_blank">haskell-bounces@haskell.org</a> [mailto:<a href="mailto:haskell-bounces@haskell.org" target="_blank">haskell-bounces@haskell.org</a>] <b>On Behalf
Of </b>Conal Elliott<br>
<b>Sent:</b> 24 December 2007 00:15<br>
<b>To:</b> <a href="mailto:haskell@haskell.org" target="_blank">haskell@haskell.org</a><br>
<b>Subject:</b> [Haskell] garbage collection of Concurrent Haskell threads?</span></p>
</div>
</div><div class="Ih2E3d">
<p> </p>
<p style="margin-bottom: 12pt;">The classic paper "The
Incremental Garbage Collection of Processes" (<a href="http://citeseer.ist.psu.edu/baker77incremental.html" target="_blank">http://citeseer.ist.psu.edu/baker77incremental.html</a>)
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 ( <a href="http://haskell.org/haskellwiki/Reactive" target="_blank">http://haskell.org/haskellwiki/Reactive</a>),
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)?<br>
<br>
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. <br>
<br>
Thanks, - Conal<br>
<br>
<br>
</p>
</div></div>
</div>
</div>
</blockquote></div><br>