fairness in NPTL mutex
Halim Amer
amer@matsulab.is.titech.ac.jp
Mon Oct 27 15:56:00 GMT 2014
Hi
This question concerns the NPTL mutex implementation but it is tightly
related to the futex syscall. So, please let me know if you think this
is not the right place to seek answers.
In short, I would like to know if there is a way to guarantee fairness
in lock acquisition when using a mutex. AFAIK, the NPTL mutex
implementation is based on atomic operations to acquire the lock and
block on a FUTEX_WAIT if not successful. The problem arises when a the
lock is released, a thread/process wakes up with a FUTEX_WAKE but has to
race again to acquire the lock through atomic operations. Since cases
where another thread/process wins the lock instead of the one that just
woke up (ex. tight loop where the thread releases the lock will acquire
it faster than others) unfairness is happening.
This issue was already pointed out in the paper "Fuss, Futexes and
Furwocks: Fast Userlevel Locking in Linux". The authors proposed a fair
futex syscall (futex_up_fair) to avoid this problem. However it seems
like it never went to the mainstream kernel. Am I wrong, or there is no
way to achieve this behavior with the current futex available operations?
I am aware of fair lock implementations such as ticket and queue-based
locks, but I would like a lock that guarantees fairness while blocking
threads/processes in the kernel space instead of busy waiting. Any
suggestions are welcome.
Thank you,
Halim
More information about the Libc-help
mailing list