[erlang-questions] Some facts about Erlang and SMP

Bjorn Gustavsson bgustavsson@REDACTED
Wed Sep 24 10:07:10 CEST 2008


On Sat, Sep 20, 2008 at 8:08 PM, Matthew Sackman <matthew@REDACTED>wrote:

> I'm having some difficulties with the "it's only when locks conflict
> that locking time is significant" idea. My understanding with the
> pthreads locks is that you start with a CAS, and if that fails then you
> spin for a while (with CAS), and if you spin for too long then you go a
> kernel lock. If that's wrong then I'm sorry, as most of the following
> will also be wrong!
>
> Now assuming the above is correct (or at least close enough for jazz),
> in the conflict case, sure, you're going to block, which is the point,
> and then some time in the future either the kernel will wake you up
> (pretty slow), or the spinning finally succeeds in which case the
> wakeup should be really fast.
>
> If there's not a conflict then the first CAS will succeed. But a CAS is
> many hundreds of cycles as you've got to do cache-coherency and then
> really go all the way out to RAM and load the values in fresh,
> especially in a multisocket box. So hundreds of cycles does not seem
> like "not significant", at least to me. Or have I missed something
> obvious here?
>
> It depends on the context.

Compared to not having any locks at all (as in the non-SMP emulator), the
cost for taking
a lock without any conflict is significant. (That's why the non-SMP emulator
is faster
than SMP emulator running with only one scheduler.)

Compared to a lock conflict when multiple scheduler threads cannot do any
useful work
while waiting for a lock, the cost for taking a lock directly without any
conflict is not
significant.

/Bjorn
-- 
Björn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080924/e22f9f44/attachment.htm>


More information about the erlang-questions mailing list