4 ms·
Mutexes aren't necessarily fair, and there's some good reasons you may not want true fairness in your lock[1] (that said, most implementations try to be as fair
by connicpu 4y ago
Mutexes aren't necessarily fair, and there's some good reasons you may not want true fairness in your lock[1] (that said, most implementations try to be as fair as they can be without introducing too much overhead)
[1]: http://joeduffyblog.com/2006/12/14/anticonvoy-locks-in-windows-server-2003-sp1-and-windows-vista/ http://joeduffyblog.com/2006/12/14/anticonvoy-locks-in-windo...
- zamalek 4y agoRight, but spinlocks have no concept of fairness at all. With a mutex on thread might experience unfairness for a few ms, a spinlock has no bound.
- jimmyed 4y agoIt's not mutexes that are fair, it's the scheduling that is fair. Scheduling tries to prevent starvation and schedules the preempted mutex thread at least periodically.
- zamalek 4y agoThat's unnecessary pedantry, in context. I am explaining an important con of spinlocks. Whether it is because mutexes are fair or because they behave fair is completely irrelevant. The point is that if you use spinlocks (which the article incorrectly calls mutexes), then you could see unintuitive behavior under load.
- gpderetta 4y agoYou can have fair spinlocks if you handle queuing yourself. Also the article does indeed implement a real mutex (although a buggy one), not a spinlock. std::atomic::wait will use futexes (or whatever) underneath to genuinely put the process to sleep until it receives a wakeup.