<div dir="ltr">On Sat, Sep 20, 2008 at 8:08 PM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@wellquite.org">matthew@wellquite.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm having some difficulties with the "it's only when locks conflict<br>
that locking time is significant" idea. My understanding with the<br>
pthreads locks is that you start with a CAS, and if that fails then you<br>
spin for a while (with CAS), and if you spin for too long then you go a<br>
kernel lock. If that's wrong then I'm sorry, as most of the following<br>
will also be wrong!<br>
<br>
Now assuming the above is correct (or at least close enough for jazz),<br>
in the conflict case, sure, you're going to block, which is the point,<br>
and then some time in the future either the kernel will wake you up<br>
(pretty slow), or the spinning finally succeeds in which case the<br>
wakeup should be really fast.<br>
<br>
If there's not a conflict then the first CAS will succeed. But a CAS is<br>
many hundreds of cycles as you've got to do cache-coherency and then<br>
really go all the way out to RAM and load the values in fresh,<br>
especially in a multisocket box. So hundreds of cycles does not seem<br>
like "not significant", at least to me. Or have I missed something<br>
obvious here?<br>
<br></blockquote></div>It depends on the context.<br><br>Compared to not having any locks at all (as in the non-SMP emulator), the cost for taking<br>a lock without any conflict is significant. (That's why the non-SMP emulator is faster<br>
than SMP emulator running with only one scheduler.)<br><br>Compared to a lock conflict when multiple scheduler threads cannot do any useful work<br>while waiting for a lock, the cost for taking a lock directly without any conflict is not<br>
significant.<br clear="all"><br>/Bjorn<br>-- <br>Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
</div>