Hi all, <div><br></div><div>Apologies for commenting before understanding Capability.c very well. But it seems that this file uses locking quite heavily. Has there been an analysis of whether atomic memory ops and lock free algorithms could play any role here?</div>
<div><br></div><div>Simon mentioned keeping track of the number of items in the queue so as not to have to traverse it while holding the lock. That, for example, seems that it could be accomplished with an atomically modified counter.</div>
<div><br></div><div>Cheers,</div><div> -Ryan</div><div><br><div class="gmail_quote">On Wed, Nov 17, 2010 at 10:25 AM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Excerpts from Simon Marlow's message of Wed Nov 17 06:15:46 -0500 2010:<br>
<div class="im">> I suggest keeping track of the number of items in the queue.<br>
<br>
</div>Ok, I added a spare_workers_no field to the Capability struct.<br>
<div class="im"><br>
> So I think the main thing missing is a call to workerTaskStop().<br>
<br>
</div>Added.<br>
<div class="im"><br>
> It would be really nice if we could arrange that in the case where we<br>
> have too many spare workers, the extra workers exit via the same route,<br>
> but I suspect that might not be easy.<br>
<br>
</div>Do you mean, spare workers that have useful tasks to do?<br>
<font color="#888888"><br>
Edward<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br></div>