I wrote:
> Unless a developer is relying on the release-on-sleep mechanism or the
> nested-locks-without-deadlock mechanism, there's no reason an instance
> of the BKL can't be replaced with another spinlock.
Greg replied:
Um, not true. You can call schedule with the BKL held, not true for a
spinlock.
Well, this is what I meant by the release-on-sleep. When you go to
sleep, the BKL is actually released in the scheduler.
Anything which is relying on this behavior needs to be redesigned. It
is holding, at best, an advisory lock. The lock, after all, is only in
effect until you go to sleep. No other lock behaves this way. Is
there any code in the kernel which MUST have this feature? The code
should be written so that the code itself releases any locks it holds
before putting itself to sleep. "magic" which happens simply because
you down'ed a semaphore is just more obfuscated code to the uninitiated
and more trouble to even the informed.
And see the oft repeated messages on lkml about the
spinlock/semaphore hell that some oses have turned into when they
try to do this. Let's learn from history this time around please.
Fire burns, but we seem to have gotten a handle on it.
Proper locking is hard, but that's not a reason to ignore it. Be
careful, yes. Avoid, no.
Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:16 EST