[lkml]   [2005]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
    On Wed, 2005-12-14 at 11:24 +0000, Alan Cox wrote:
    > On Mer, 2005-12-14 at 12:08 +0100, Arjan van de Ven wrote:
    > > 1) the BKL change hasn't finished, and we're 5 years down the line. API
    > > changes done gradual tend to take forever in practice, esp if there's no
    > > "compile" incentive for people to fix things.
    > This isn't a "fix" however, its merely a performance tweak.

    it's a conceptual API split that, if nothing else, declares intent and
    usage pattern more specifically. Performance is just one of the angles.
    Other angles are that it's possible to treat mutex users different (like
    Ingo is doing in -rt, where you can temporary boost a mutex owner if the
    mutex gets contended, other uses are better hold time metrics etc etc)

    > Drivers
    > using the old API are not a problem because
    > a) The old API is needed long term for true counting sem users

    this is skipping one bridge ;)
    A counting semaphore is needed long term. API is up for debate in the
    sense that it's not clear that a non-compile-time thing is the right

    > Thats rather different to the BKL

    BKL is different in that it's more work to do a conversion (eg the BKL
    semantics are rather complex compared to normal spinlock / semaphore /
    mutex semantics). So yes BKL is harder, and not really possible to do in
    one go. Unlike these...
    For BKL there was no choice. Here there is.

    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-12-14 12:44    [W:0.021 / U:39.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site