Messages in this thread | | | From | Nikita Danilov <> | Date | Mon, 19 May 2003 15:37:52 +0400 | Subject | Re: recursive spinlocks. Shoot. |
| |
Helge Hafting writes: > Peter T. Breuer wrote: > > > Hey, that's not bad for a small change! 50% of potential programming > > errors sent to the dustbin without ever being encountered. > > Then you replace errors with inefficiency - nobody discovers that > you needlessly take a lock twice. They notice OOPSes though, the > lock gurus can then debug it. > > Trading performance for simplicity is ok in some cases, but I have a strong > felling this isn't one of them. Consider how people optimize locking > by shaving off a single cycle when they can, and try to avoid > locking as much as possible for that big smp scalability. > > This is something better done right - people should just take the > trouble.
There, however, are cases when recursive locking is needed. Take, for example, top-to-bottom insertion into balanced tree with per-node locking. Once modifications are done at the "leaf" level, parents should be locked and modified, but one cannot tell in advance whether different leaves have the same or different parents. Simplest (and, sometimes, the only) solution here is to lock parents of all children in turn, even if this may lock the same parent node several times---recursively.
> > Helge Hafting >
Nikita.
- 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/
| |