Hacker News Reader

Comment by m4nu3l | Hacker News Reader

That's my understanding too. In Linux mutexes are implemented by futexes (Fast User-Space mutexes). If there is no contention they are guaranteed to not perform a syscall https://en.wikipedia.org/wiki/Futex

View on HN

Maybe this has changed, but last time I looked at futexes there was no syscall for locking (assuming no contention), but unlocking always made a syscall. This was many years ago so it could be different now.

The code isn't the easiest to read but in glibc it seems that the syscall is only performed if waiters are detected in userspace during an unlock operation

https://github.com/lattera/glibc/blob/master/nptl/pthread_mu...

Indeed You only need to FUTEX_WAKE if you know there are waiters (or of you lost track of the number of waiters).

What can cause the mutex to lose track of the number of waiters?

Generally you have a small number of bits to count the waiters, because the mutex state has to be a word you can CAS and so you have either 32 or 64 bits to pack all the state you need. If your counter saturates you lose track of the waiters, and you have to fallback somehow.

Makes sense, thanks for the explanation!

Although it's not the code C++ will be using the Rust implementation is a bit easier to follow:

https://doc.rust-lang.org/src/std/sys/unix/locks/futex_mutex...

Unlock is just:: self.futex.swap(0, Release) -- if the value we get back is 2 then we know at least one thread is asleep waiting on this futex, so we need a system call to wake them, but in the uncontended case we're done immediately.

Reply on news.ycombinator.com