lkml.org 
[lkml]   [2005]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/19] MUTEX: Introduce simple mutex implementation
    Date
    Andrew Morton <akpm@osdl.org> wrote:

    > I must say that my interest in this stuff is down in
    > needs-an-electron-microscope-to-locate territory. down() and up() work
    > just fine and they're small, efficient, well-debugged and well-understood.
    > We need a damn good reason for taking on tree-wide churn or incompatible
    > renames or addition of risk. What's the damn good reason here?

    Well...

    (1) On some platforms counting semaphores _can't_ be implemented all that
    efficiently because the only atomic op you've got is something very
    simple that can only unconditionally exchange one state for another
    (XCHG/TAS/SWAP). In such cases counting semaphores have to be be
    implemented by disabling interrupts and taking spinlocks.

    Okay, spinlocks are null ops when CONFIG_SMP and CONFIG_DEBUG_SPINLOCK
    are both disabled, but you still have to disable interrupts, and that
    slows things down, sometimes quite appreciably. It is, for example,
    something I really want to avoid doing on FRV as it takes a *lot* of
    cycles.

    (2) I think Ingo has some RT requirements, but he's probably better to speak
    about them.

    (3) As a slight aside, in a number of cases counting semaphores and their
    operators are being misused: there are, for example, places where
    completions should be used instead and places where *_MUTEX_LOCKED are
    used to initialise counting semaphores. There are also cases in there
    that seem unsure as to whether they're using counting semaphores or
    mutexes.

    Whilst this is not an argument for a galaxy wide churn, in and of itself,
    it does show that a good review is needed and at the very least these
    cases need to be fixed.

    (4) Various people want a mutex for which the semantics are tighter: in
    particular requiring that mutexes must be released in their owner's
    context. This makes debugging easier.

    (5) Mutexes can catch a double-release, which counting semaphores by their
    very nature can't.

    So... Would you then object to an implementation of a mutex appearing in the
    tree which semaphores that are being used as strict mutexes can be migrated
    over to as the opportunity arises?

    David
    -
    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-12-15 16:40    [W:0.032 / U:0.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site