Use of spinlocks in Erlang

Andreas Schultz andreas.schultz@REDACTED
Wed Jan 15 17:54:27 CET 2020


Am Mi., 15. Jan. 2020 um 17:41 Uhr schrieb Jesper Louis Andersen <
jesper.louis.andersen@REDACTED>:

> On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz <
> andreas.schultz@REDACTED> wrote:
>
>>
>> Could any of the Erlang gurus or ERTS developers comment on the use of
>> home grown mutexes and spinlocks in Erlang in light of that discussion?
>>
>>
> Not a locking expert in the ERTS, but:
>
> The locking API is there to provide a factoring point for the BEAM. The
> idea is that we have a locking API to use in ERTS which then maps to
> different implementations as we see fit. This allows us to target both
> UNIX, Windows, and embedded OS'es at the same time, with a consistent API.
> But it gets better than that!
>
> We can use the factoring point to "plug in" different locking models and
> try them out. This allows us to choose a locking model which works well. It
> also allows us to plug in various debugging/correctness checks at compile
> time. For instance that lock ordering is preserved, if locks are contended
> on, or if a deadlock happened.
>
> That is, the current locking model is sort-of chosen at compile time,
> based on the capabilities of the underlying system.
>
> All in all, I'm going to claim that the system is not so much "home grown"
> as it is a sensible wrapper around an underlying system.
>

I have seen the different underlying implementations for the locking
primitives. There are wrappers for Windows and POSIX threads (pthread). But
there also seems to be a completely independent implementation of mutexes
and spinlocks that does not use the OS or libc provided primitives.
On Linux that Erlang specific implementation appears to be used by default
(that is what I called "home grown"). The pthread version is only used when
Erlang is build with valgrind support (or so it seems).

I was thinking about hacking a build to use only the pthread locking
primitives (without the other valdrind overhead) and run some benchmarks.
However, my hope was that some Erlang expert could shed some light in the
locking before I spent the time to do that.

Anyhow, does anybody have a suggestion for an existing benchmark that could
demonstrate differences between locking primitives?

Andreas


>
> --
> J.
>


-- 

Andreas Schultz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200115/a8570b12/attachment.htm>


More information about the erlang-questions mailing list