| |||||||||||
The Big Kernel Lock lives onThe Big Kernel Lock lives onPosted May 27, 2004 12:33 UTC (Thu) by brugolsky (subscriber, #28)In reply to: The Big Kernel Lock lives on by corbet Parent article: The Big Kernel Lock lives on 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.
(Log in to post comments)
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.
|
|||||||||||