Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
The Big Kernel Lock lives onThe Big Kernel Lock lives onPosted May 27, 2004 11:54 UTC (Thu) by corbet (editor, #1)In reply to: The Big Kernel Lock lives on by ncm Parent article: The Big Kernel Lock lives on The BKL is a special lock; its purpose still, essentially, is to protect resources not covered by some other lock. Modern code running under the BKL may well take other locks, but it will be unaware of it - the locks will be taken further down the call chain. Once the code itself becomes lock-aware, the need for the BKL should go away. And yes, it is actually quite important to define the order in which locks are taken. If the same two locks can be taken in either order, the system will eventually deadlock. Lock ordering rules (and, in general, figuring out which locks you need) get to be a real problem as the number of locks grows; people like Larry McVoy have been warning for years that overly fine-grained locking leads to an unmaintainable kernel.
(Log in to post comments)
The Big Kernel Lock lives on Posted May 27, 2004 12:33 UTC (Thu) by brugolsky (subscriber, #28) [Link] I'm sure that you meant this, but just to clarify: fine-grained locks, in and of themselves, are not the problem. One can lock a list, or lock the individual elements; the choice generally impacts performance. Excessive lock depth (i.e., level of nesting) results in an unmaintainable code. It seems to be generally agreed that the cliff lies not far beyond four locks.
The Big Kernel Lock lives on Posted May 27, 2004 23:43 UTC (Thu) by nix (subscriber, #2304) [Link] `Seven, plus or minus two'... and since we don't want to restrict kernel maintainership to those who are lucky enough to have big short-term memories, less than five seems a good point to stop.
The Big Kernel Lock lives on Posted Jun 2, 2004 22:30 UTC (Wed) by shane (subscriber, #3335) [Link] Not to speak for Mr. Corbet, but I'm pretty sure he actually wasreferring to having too many locks. The problem is deadlock: one thread holding lock A, waiting for lock B; the other holding lock B, waiting for lock A. This is the simplest example (well, holding A and waiting for A is simpler, but you get the idea). Any circular chain of references is possible, and causes the same problem. This problem is easier to hit when you use many different locks. A programmer's natural inclination is to lock each resource as you need it. However, in order to prevent deadlock you should always lock in the same order. Which means that if any thread ever needs lock A and lock B, it always locks A and then lock B. This is not always optimal, as lock A may be held for a period of time when it is not needed.
|
|||||||||||