[libcxx-commits] [PATCH] D148681: [libc++] Make std::mutex use ADAPTIVE_NP intializer if available on gnu

[Noah Goldstein via Phabricator via libcxx-commits]

goldstein.w.n added a comment.

In D148681#4279326 <https://reviews.llvm.org/D148681#4279326>, @goldstein.w.n wrote:

> In D148681#4279310 <https://reviews.llvm.org/D148681#4279310>, @philnik wrote:
>
>> Looking at https://stackoverflow.com/questions/19863734/what-is-pthread-mutex-adaptive-np I don't think we want to do this change. If someone needs such a special mutex, I guess they have to implement it themselves. We have to provide a useful mutex for all cases, not just for low contention cases that only have short times during which the mutex is locked.
>
> I don't think the SO link really does justice to the reality of the implementation.
> At the very least since the SO post was been written the following have been
> added.
>
> 1. expo backoff to avoid memory traffic
> 2. Read guards on the CAS (same as above as exclusive state in mind)
>
> It still hits the `futex`, just not immediately as doing so has a serious
> latency cost.
>
> Spinning ~100 times with a dozen or so memory accesses (with likely 
> all of them read-only) has a minimal cost in the high contention case 
> (its +maybe 100-200 cycles but the futex alone is 10-100x that) and 
> helps ALOT in the lower contention case (avoids really expensive syscalls).
>
> Edit: To be clear. I belive ADAPTIVE_NP is the generic implementation that
> does well in all cases whereas TIMED_NP is the specialized.

Also FWIW, the fast both is identical for both of them. The only difference
is whether they handle contention by just going directly to futex (TIMED_NP)
or spin for an adaptive number of iterations <= 100 (ADAPTIVE_NP).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148681/new/

https://reviews.llvm.org/D148681