<div dir="ltr"><br><div style>While trying to dig around this morning I started adding clang-style thread locking annotations to the source code. These can be very handy and I found at least one place where the documented locking policy doesn't seem to match what is happening.</div>
<div style><br></div><div style>Here is an example with annotations, and what might or might not be a bug. With these annotations, clang will be able to prove whether the program obeys the locking regime or not.</div><div style>
<br></div><div style>But this is of course only one part of the RTS, but the locking can be pretty "interesting" in itself.</div><div style><br></div><div style>Does anyone else feel that this sort of annotations would help?</div>
<div style><br></div><div style>Alexander</div><div style><br></div><div style><div>diff --git a/rts/Task.c b/rts/Task.c</div><div>index e6781a1..1e499dc 100644</div><div>--- a/rts/Task.c</div><div>+++ b/rts/Task.c</div>
<div>
@@ -25,12 +25,12 @@</div><div> </div><div> // Task lists and global counters.</div><div> // Locks required: all_tasks_mutex.</div><div>-Task *all_tasks = NULL;</div><div>+Task *all_tasks GUARDED_BY(all_tasks_mutex) = NULL;</div>
<div> </div><div>-nat taskCount;</div><div>-nat workerCount;</div><div>-nat currentWorkerCount;</div><div>-nat peakWorkerCount;</div><div>+nat taskCount GUARDED_BY(all_tasks_mutex);</div><div>+nat workerCount GUARDED_BY(all_tasks_mutex);</div>
<div>+nat currentWorkerCount GUARDED_BY(all_tasks_mutex);</div><div>+nat peakWorkerCount GUARDED_BY(all_tasks_mutex);</div><div> </div><div> static int tasksInitialized = 0;</div><div> </div><div>@@ -339,9 +339,11 @@ void updateCapabilityRefs (void)</div>
<div> ACQUIRE_LOCK(&all_tasks_mutex);</div><div> </div><div> for (task = all_tasks; task != NULL; task=task->all_next) {</div><div>+ ACQUIRE_LOCK(task->lock);</div><div> if (task->cap != NULL) {</div>
<div> task->cap = &capabilities[task->cap->no];</div><div> }</div><div>+ RELEASE_LOCK(task->lock);</div><div> </div><div> for (incall = task->incall; incall != NULL; incall = incall->prev_stack) {</div>
<div> if (incall->suspended_cap != NULL) {</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 2:14 PM, Chris Dornan <span dir="ltr"><<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>I am also sorry to be late on this but I have run into the same problem trying to demonise a programme on 7.4.2. My solution was to get a shell wrapper to run the daemon in debug mode (I.e., sans fork) and get the shell script to do the demonising.</div>
<div><br></div><div>Other than this I have found the threaded RTS to be sound and I am quite reliant on it. So, where things that run —threaded are concerned, no forkProcess calls for me until I can better understand this better.</div>
<div><br></div><div>If anybody does think they understand what is going on here it would be great if they could write it up. IMHO, either the current notes on forkProcess don't go far enough, or there is a bug needing a workaround until the platform gets fixed.</div>
<div><br></div><div>Chris</div><div><br></div><span><div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span> Mark Lentczner <<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@gmail.com</a>><br><span style="font-weight:bold">Date: </span> Sunday, 20 January 2013 23:15<br>
<span style="font-weight:bold">To: </span> haskell <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br><span style="font-weight:bold">Cc: </span> Mike Meyer <<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [Haskell-cafe] forkProcess, forkIO, and multithreaded runtime<br></div><div><div class="h5"><div><br></div><div dir="ltr">Sorry to be reviving this thread so long after.... but I seem to be running into similar issues as Michael S. did at the start.<div>
<br></div><div>In short, I'm using forkProcess with the threaded RTS, and see occasional hangs:</div><div class="gmail_extra"><ul><li>I see these only on Linux. On Mac OS X, I never do.</li><li>I'm using GHC 7.4.2</li>
<li>I noticed the warning in the doc for forkProcess, but assumed I was safe, as I wasn't holding any shared resources at the time of the fork, and no shared resources in the program are used in the child.</li><li>WIth gdb, I've traced the hang to here in the run-time: <font face="courier new,monospace">forkProcess > discardTasksExcept > freeTask > closeMutex(&task->lock) > pthread_mutex_destroy</font></li>
</ul>The discussion in this thread leaves me with these questions:</div><div class="gmail_extra"><ul><li>Is there reason to think the situation has gotten better in 7.6 and later?</li><li>Isn't the only reason <b>System.Process</b> is safer because it does an immediate exec in the child? Alas, I really want to just <font face="courier new,monospace">fork()</font> sometimes.</li>
<li>Is it really true that even if my program has no shared resources with the child, that the IO subsystem and FFI system do anyway? Surely the RTS would take care of doing the right thing with those, no?</li><li>
There should be no concern with <font face="courier new,monospace">exec</font> w.r.t. library invariants since <span style="font-family:'courier new',monospace">exec</span> is wholesale replacement - all the libraries will reinitialize. Is there a problem here I'm missing?</li>
</ul>Alas, I've stopped using the threaded RTS until I understand this better.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Mark</div></div></div></div><div class="im">
_______________________________________________
Haskell-Cafe mailing list
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>
</div></span></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>