Jörn Engel (joern.delete@this.purestorage.com) on January 5, 2020 1:45 pm wrote:
> One thing I noticed while watching Weiman's presentation is an off-hand remark that FUTEX_LOCK_PI
> has worse performance than FUTEX_WAIT. Do you happen to know why that is the case?
> In particular, is that a fundamental limitation or just a bug we can fix?

I think it's just that FUTEX_WAIT is a fundamentally simpler operation, and when it works for your load, there's just much less setup and complexity.

FUTEX_LOCK_PI is rather fancier, and is a rather more complete locking model, but that also implies a fair amount more housekeeping.

But take any performance numbers with a big pinch of salt. It will depend on what your requirements are, and what your load is, and what your hardware is like.

For an example of something that can be a big performance issue: do you require that a thread suddenly dying will release any locks it held? Because if you do, then you almost have to use a locking library that uses a system call for every single lock - so that the system can keep track of them and release them if the process is killed by a SIGSEGV (or a SIGKILL) while holding the lock.

Conversely, if you're ok with "if somebody kills a lock holder, then things break", you can do the user-space fast-case handling without worrying about "what if this thread now dies and nobody else knows about it holding the lock".

My personal opinion is that it makes no sense at all to have cleanup on thread death - if it held a lock while dying, you can't rely on the data structures that that lock protected anyway, so trying to "clean up" is just silly. But not everybody agrees with me, and some people want that EOWNERDEAD kind of error handling capability, which pretty much requires a large extra set of complexity (and a performance hit).

This is just one example why a custom locking library may be a better choice for you than some generic locking model: there are a lot of corner case issues wrt lock handling that may or may not be things you care about, but that can have a big impact on performance.

So it's not just about the lock working as a lock. There's fairness, priority inheritance, recursion handling, debug capabilities, exception handling, etc etc. Things like having the capability to time out a lock can be surprisingly complicated too, so various interface requirements can be a (surprisingly) big deal.

Linus