[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.023 / U:59.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site