[lkml]   [2005]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/12]: MUTEX: Implement mutexes
    Linus Torvalds <> wrote:

    > I still don't see the reason for _any_ of these changes.
    > There's one big reason to stay with what we have: it's always better to
    > not make changes unnecessarily. That's a BIG reason. It's the _changes_
    > that need to have strong arguments for them as actually buying us
    > something.

    I assume your referring to the introduction of the specific mutex concept as a
    whole, not just renaming DECLARE_MUTEX.

    For certain architectures, only interrupt disablement, basic spinlocks and
    mutexes can be implemented directly; all other synchronisation primitives have
    to be implemented in terms of these. For the purpose of this discussion, I'm
    ignoring the architectures that might not even have that much; as far as I can
    see, such as those can't be made to do SMP at all SMP, and so there interrupt
    disablement is the only requirement.

    Linux supports a number of those archs. Amongst them are 68000 (TAS), arm (SWP
    I think), i386 (XCHG), and FRV (SWAP). I'm also looking at another that only
    has BSET/BCLR.

    All of these can only atomically do an unconditional exchange of one state for
    another, sufficient to implement a spinlock. They may then use spinlocks and
    interrupt disablement to sandwich the semaphore implementation, or they may not
    even try to make semaphores fully atomic.

    Furthermore, having to disable interrupts can be a slow process on some archs,
    notably FRV as far as I'm concerned - though a cute way to do this lazily has
    been pointed out. Still, I need to use spinlocks to implement semaphores.

    Since only about a dozen of the usages of semaphores are actually _as_
    semaphores, and the other 400 or so are as mutexes, being able to speed up
    the mutex implementation drastically would be a very big plus.

    Note also that almost all (if not all) the usages of counting semaphores are in
    the drivers, and none (or almost none) are in the core code, this would be a
    really big win, and would possibly allow counting semaphores to be ditched
    entirely on platform configurations where they're not needed.

    There are also other reasons for defining a strict mutex type: by forcing the
    restriction of the type, it makes it harder to accidentally violate the
    semantics (something that's all too easy with counting semaphores); further,
    this makes it easier to debug as it's easier to catch errors when they do
    happen. Also, as I understand it, Ingo suggests that having a separate mutex
    type will make realtime constraints easier to deal with.

    Now, whilst you may have concerns that this will mess everything up, I think
    disruption can be held to a minimum by making the default case a simple wrapper
    around the counting semaphores. That way any platform in which the semaphore
    implementation is pretty much optimal as a mutex already (for instance x86), no
    changes need to be made to the arch.

    The big problem with doing it this way is that it will incur more source churn
    as semaphores are turned into mutexes. However, if you want the counting
    semaphore API to stay exactly as it is now, and the changes to be limited to a
    direct rename only (with no other changes to existing code, except perhaps the
    inclusion of an extra header file), that is possible:

    struct semaphore -> struct mutex
    init_MUTEX -> mutex_init
    init_MUTEX_LOCKED -> mutex_init_locked
    DECLARE_MUTEX_LOCKED -> [should probably be using a completion]
    down -> mutex_lock
    down_interruptible -> mutex_lock_interruptible
    down_trylock -> mutex_trylock
    up -> mutex_unlock
    sem_is_locked -> mutex_is_locked

    Whilst it would be nice to script these changes, I'm not sure it's entirely
    practical, unless we change _all_ counting semaphores to mutexes, and then
    convert back those that _should_ be counting semaphores. Doing that, however,
    would reduce the chances of error greatly.

    So please don't just turn down mutexes because you aren't interested in
    "lesser" architectures. We should be able to guarantee that the mutexes won't
    be any worse than counting semaphores for implementing mutexes - even on major
    architecture - if only by wrapping the counting semaphore so that we can check
    the constraints aren't violated when the debugging is turned on.

    As I suggested above, I can change the mutex patches so that it's merely a
    matter of renaming the symbols, which can possibly be scripted; that should
    reduce the chance of errors drastically.

    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-17 20:25    [W:0.024 / U:2.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site