3 ms·

I don't know how I should feel about changes like this. My concern with 'spinlocks in userspace' (i.e., locks that don't just call into the futex API when they

I don't know how I should feel about changes like this. My concern with 'spinlocks in userspace' (i.e., locks that don't just call into the futex API when they run into contention) is that they merely try to optimize for their own performance. Sure, the futex API has more overhead, but it does mean that other processes on your system can run in the meantime. It's sort of similar to using a TCP congestion algorithm that's overly aggressive. Your own network connections might become faster as a result of them, but at the same time your flatmates won't be able to check their mail.

saagarjha 3y ago
Generally unbounded spins are terrible in userspace, but bounded spins as part of "hybrid" locks generally strike a good balance between performance and system impact. When a system call is hundreds or thousands of cycles it can be quite effective to try spending some fraction of that yourself if it'll get you the lock without the syscall. Like, not just from a pure throughput perspective: a yield to the kernel is not "free", it takes time just to park yourself. So it's good to make a gamble usually.
- amelius 3y ago
  Could the implementation of the lock perhaps take the thread priority into account?
  - saagarjha 3y ago
    What would it do differently?
    - amelius 3y ago
      Give up earlier when the priority is low, so performance impact is low for low-priority threads.