2.5: push BKL out of llseek
Quoted 2 lines · Martin Wirth
void
combi_mutex_lock(struct combilock *x)
.....
Quoted 3 lines
} else <---
x->owner=current;
spin_unlock(&x->wait.lock);Uugh, the else is wrong of course. The owner has to be set in any case.(Just deleted some debugging code and reformatted a bit to quick :))
A further note: Although the combilock shares some advantages with a spin-lock (no unnecessary scheduling for short time locking) it may behave like a semaphore on entry also if you call combi_spin_lock. For example
spin_lock(&slock);
combi_spin_lock(&clock);is a BUG because combi_spin_lock may sleep while holding slock!
Would be nice if there were some comments.
Martin Wirth
Quoted 11 lines · Martin Wirth
A further note: Although the combilock shares some advantages with a spin-lock (no unnecessary scheduling for short time locking) it may behave like a semaphore on entry also if you call
combi_spin_lock. For examplespin_lock(&slock); combi_spin_lock(&clock);is a BUG because
combi_spin_lockmay sleep while holding slock!Would be nice if there were some comments.
Nice work! This could turn out to be a useful tool for those of us working on reliable low-latency kernels. I certainly agree that it is a much better solution than adaptive spinlocks (which dynamically decide when to sleep) as the kernel programmer should always know whether a spinlock or a sleep lock is more appropriate.
Unfortunately, as you point out, it's not as useful as it may first appear in the short term, because last time I looked into the problem of long-held spinlocks they were all nested under other spinlocks and/or the BKL.
Nigel Gamble [email protected]
Mountain View, CA, USA. http://www.nrg.org/