<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yuck!<div><br></div><div>Look, any reasonable implementation of critical sections/mutexes on modern multi-cores will use spin locks so uncontended accesses to speed the fast path in acquisition. This will be implemented using CAS or LL/SC which on many architectures also have the effect of a membar. This is all just premature optimization! Measure it! If it is slow, then worry about how to make it fast! Otherwise, keep it simple!<br><div><font class="Apple-style-span" color="#0000FF" face="'Gill Sans'"><font class="Apple-style-span" color="#000000" face="Helvetica"><br></font></font></div><div><div><div>On 12 Nov 2009, at 09:28, <a href="mailto:hendrik@topoi.pooq.com">hendrik@topoi.pooq.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Nov 12, 2009 at 04:17:12AM +0000, Jay K wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">I do currently still use the critical section "throughout 'all' of AssignSlot".<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The memory barrier doesn't replace it there. Just makes it carefully <br></blockquote><blockquote type="cite">ordered so other readers see things reasonably well.<br></blockquote><br>Just curious: C had "volatile" variables, meaning variables whose <br>writes and reads cannot be reordered or deleted by an optimiser. <br>They're intended for things like memory-mapped I/O. Wouldn't they be <br>the kinds of things we need here? How does the gcc intermediate code <br>represent them? By memory barriers? Or by some other means?<br><br>-- hendrik<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I DO suspect the locking in AssignSlot can be reduced but haven't done so yet.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Maybe it doesn't work out.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> - Jay<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">From: <a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br></blockquote><blockquote type="cite">To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br></blockquote><blockquote type="cite">Date: Wed, 11 Nov 2009 09:23:59 -0500<br></blockquote><blockquote type="cite">CC: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br></blockquote><blockquote type="cite">Subject: Re: [M3devel] FreeSlots/lookup slot locking<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It's not the allocation I worry about.<br></blockquote><blockquote type="cite">How do you avoid two threads getting the same slot?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 11 Nov 2009, at 01:11, Jay K wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Tony:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Also, I am unconvinced that the current implementation of AssignSlot can ever<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be correct without the critical section. It requires atomic update of both<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the slots array pointer (with the new slots) *and* the array elements. This<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">requires a proper CS instead of non-blocking synchronization.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't see it.<br></blockquote><blockquote type="cite">I could be wrong.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The writes are done within a critical section, to avoid racing with other writers.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Writes interact with readers in that:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> SUBARRAY (new_slots^, 0, n) := slots^;<br></blockquote><blockquote type="cite">finish writing to the array elements<br></blockquote><blockquote type="cite">MemoryBarrier<br></blockquote><blockquote type="cite"> slots := new_slots;<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">so readers don't see slots unless it has been fully initialized.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">AssignSlots should also be able to be lock free via InterlockedCompareExchangePointer.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> - Jay<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span> <br></blockquote></div></blockquote></div><br></div></div></body></html>