lkml.org 
[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: BKL removal
    Date
    From
    I wrote:

    > Unless a developer is relying on the release-on-sleep mechanism or the
    > nested-locks-without-deadlock mechanism, there's no reason an instance
    > of the BKL can't be replaced with another spinlock.

    Greg replied:

    Um, not true. You can call schedule with the BKL held, not true for a
    spinlock.

    Well, this is what I meant by the release-on-sleep. When you go to
    sleep, the BKL is actually released in the scheduler.

    Anything which is relying on this behavior needs to be redesigned. It
    is holding, at best, an advisory lock. The lock, after all, is only in
    effect until you go to sleep. No other lock behaves this way. Is
    there any code in the kernel which MUST have this feature? The code
    should be written so that the code itself releases any locks it holds
    before putting itself to sleep. "magic" which happens simply because
    you down'ed a semaphore is just more obfuscated code to the uninitiated
    and more trouble to even the informed.

    And see the oft repeated messages on lkml about the
    spinlock/semaphore hell that some oses have turned into when they
    try to do this. Let's learn from history this time around please.

    Fire burns, but we seem to have gotten a handle on it.

    Proper locking is hard, but that's not a reason to ignore it. Be
    careful, yes. Avoid, no.

    Rick
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:0.027 / U:121.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site