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/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:34 EST