>From what I understand Barry doesn't want the threads to spin.<div>Also, synchronizing through an unguarded memory location seems to create a race conditions.</div><div>Isn't cmpxchg instruction-set specific?</div>

<div><br></div><div>Dmitry.<br><br><div class="gmail_quote">On Tue, Nov 29, 2011 at 8:50 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<p>You don't need any of this unless your threads need to actually sleep instead of spin. I think we can afford to have them spin, so we don't need any locking. You let the threads continue by doing an ordinary write to a memory location. (You can do more sophisticated things with cmpxchg, which you likely need at synchronization points.)</p>

<div class="HOEnZb"><div class="h5">

<div class="gmail_quote">On Nov 29, 2011 8:41 AM, "Dmitry Karpeev" <<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Barry,<div><br></div><div>You might want to take a look at this:  <a href="http://stackoverflow.com/questions/2994216/linux-pthread-suspend" target="_blank">http://stackoverflow.com/questions/2994216/linux-pthread-suspend</a></div>


<div>The solution suggested there (Answer 1) is to use sigwait().  Answer 3, although not the actual solution,</div>

<div>explains why the  pthread_suspend/pthread_continue-based solution is racy. I think this may be a general issue </div><div>with the problem, which requires the use of mutexes.  </div><div><br></div><div>What example do you use to test this?  I'd like to take a look.</div>




<div><br></div><div>Thanks.</div><div>Dmitry.</div><div><br><div class="gmail_quote">On Thu, Nov 24, 2011 at 4:10 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">On Thu, Nov 24, 2011 at 16:01, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>  Yes, but they can only get access to that shared variable one at a time: first get's it, then second get's it, then third gets, .... Ok for a couple of cores but not for dozens.<br>
<br>
   Take a look at src/sys/objects/pthread.c for the various ways we have coded for "waking" the threads. Maybe I am missing something but this is the best Kerry and I could figure out.</div></blockquote></div><br>





</div><div>What exactly should I be looking at? Can't you have all the threads spin on a normal shared variable (not a mutex) that is only written by the thread that needs to spark them? Or use a fetch-and-add atomic if you want to keep track of how many are running or limit the number? The latter could use a tree to get logarithmic cost, but if they are stored next to each other, you would still have O(P) cache invalidations.</div>





</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>