<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, Jan 7, 2020 at 10:01 AM Andreas Schultz <<a href="mailto:andreas.schultz@travelping.com">andreas.schultz@travelping.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,Tahoma,sans-serif;font-size:14px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,Tahoma,sans-serif;font-size:14px">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?</span><br></div><div><br clear="all"></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Not a locking expert in the ERTS, but:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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!</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">That is, the current locking model is sort-of chosen at compile time, based on the capabilities of the underlying system. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">J.</div></div>