Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Why both conditions? Because a second thread will also get the lock in that case. <em>(Edit: but that case can't happen if all threads follow the spinlock protocol.)</em></p> <p>If the lock is available (signaled) <code>m_s</code> has the value 1. When taken by some thread, it has the value 0. No other values are allowed.</p> <p>Consider one thread that wants the lock, whether or not it is signaled at the moment that thread called <code>Enter()</code> is unimportant. It is allowed to take the lock if <code>m_s</code> is 1, and it takes by changing it to 0. The first iteration where that happens causes the loop to exit and the thread to have the lock.</p> <p>Now consider two threads that want the same lock. Both are calling <code>TestAndSet()</code>, waiting to see the value 1 become 0. Because the function <code>TestAndSet()</code> is atomic, only one of the waiting threads ever gets to see the value 1. All the other threads only ever see <code>m_s</code> as 0, and must continue to wait.</p> <p>The condition where <code>m_s</code> is 1 after setting it to 0 in this thread implies that some other thread signaled between the atomic operation and the condition. Since only one thread at a time is supposed to have the lock, <strike>it seems like it shouldn't happen</strike> that can't happen. </p> <p>I'm guessing that this is an attempt to satisfy the invariant promise of the spinlock. <em>(Edit: I'm no longer so sure, more below...)</em> If it is held, the value of <code>m_s</code> must be zero. If not, it is one. If setting it to zero didn't "stick", then something weird is happening, and it is best not to assume it is now held by this thread when the invariant is not true.</p> <p><strong>Edit:</strong> Jon Skeet points out that this case might be a flaw in the original implementation. I suspect he's right. </p> <p>The race condition that is being guarded is against a thread that <strong>doesn't have the right to signal the spinlock</strong>, signaling the spinlock anyway. If you can't trust callers to follow the rules, spinlocks probably aren't the synchronization method of choice, after all.</p> <p><strong>Edit 2:</strong> The proposed revision looks much better. It would clearly avoid the multi-core cache coherency interaction that the original had due to always writing the sentinel <code>m_s</code>. </p> <p>After reading about the <a href="http://en.wikipedia.org/wiki/Test_and_Test-and-set" rel="nofollow noreferrer">TATAS protocol</a> (you can learn something new every day, if you pay attention...) and the multicore cache coherency issue it is addressing, it is clear to me that the original code was trying to do something similar, but without understanding the subtlety behind it. It would indeed have been safe (assuming all callers follow the rules) to drop the redundant check on <code>m_s</code> as it was written. But the code would have been writing to <code>m_s</code> on every loop iteration, and that would have played havoc in a real multicore chip with caching per core.</p> <p>The new spinlock is still vulnerable to a second thread releasing it without holding it. There is no way to repair that. My earlier claim about trusting the callers to follow protocol still applies.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload