Recent Features
| |||||||||||||
Preventing overly-optimistic spinningPreventing overly-optimistic spinningPosted Aug 30, 2010 17:25 UTC (Mon) by dvhart (guest, #19636)Parent article: Preventing overly-optimistic spinning
As I'm working on a similar mechanism for user-space mutexes, this caught my eye. One concern I have with the "if owner-changed then sleep" approach is the possibility of effectively disabling spinning for all but the first spinner. Perhaps this is unavoidable. I have considered an "only one spinner at a time" approach, and while it avoids a bunch of spinners stacking up, it has the same end result. I suppose workloads for which this is a benefit are not so concerned about a single block of threads trying to acquire a lock once, but rather several threads repeatedly trying to acquire the lock for the duration of the run. In this latter case, a heavily contended lock will frequently have a spinner. I wonder if the single spinner limitation would allow the system itself to perform better (on other things).
(Log in to post comments)
Preventing overly-optimistic spinning Posted Sep 3, 2010 8:20 UTC (Fri) by efexis (guest, #26355) [Link]
Do locks get served in a first-come-first-served basis? If so, a single spinner solution would be an advantage, but if not, what you'd be doing is preempting a schedular decision, as a lock might not be passed to the first spinner, but to the one with the highest priority. You wouldn't want the high priority task to sleep because a low priority task started spinning first, and then have to wake the high priority task when the lock becomes available, have the low priority task notice an ownership change and then sleep.
Are there other useful things that can be done while spinning on the processor that add latency to waking up when the lock is gained? Like saving power? Or does switching power states tend to be too hungry an operation in itself? Am just curious as a non-kernel-hacker :-)
|
|||||||||||||