[lkml]   [2003]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.128 / U:5.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site