Hacker News new | past | comments | ask | show | jobs | submit login

What OS do you have in mind? Apparently OSX locks are fair, but the downside is that this may reduce throughput.

Linux locks? I have no idea and would be interested to know.

I suspect that occasionally fair locks would be ideal, but I don't know if they can be implemented efficiently.




pthreads don't guarantee fairness. futexes, the underlying locking primitive on Linux and the driver of the glibc implementation, don't either.

Futexes do support priority inheritance, so you can use process priority safely. You might drop priority after releasing a lock to ensure some other thread gets a go, and as long as you control the priority of the other contenders, that can work well.

Basics of futexes are here, but nothing about PI or fairness: https://eli.thegreenplace.net/2018/basics-of-futexes/


Fairness is expensive. A lock must go to the thread that is eligible to get that lock according to fairness, even if another ineligible thread is executing on a CPU and is ready to grab that lock. The ineligible thread is forced to block, and the ineligible one may have to be woken up and assigned to a CPU. Until the eligible thread is dispatched and grabs the lock, multiple cores may wastefully go through a thread switch due to hitting that lock instead of just grabbing and releasing it.


Ironically, priorities as a way of "giving control" to another thread only work if you have a shortage of CPU cores. On my 24-core workstation I can normally run all runnable threads, regardless of priority. The implications are non-obvious.


Yes because if you have a shortage of cores, you have more threads that are blocked or in a run queue. When you have threads queued, that's when prioritizing works: you need a backlog of waiting threads in order to choose the "best" one to proceed. If threads have cores, the prioritizing loses value.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: