Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation

[David Howells]

Andrew Morton <akpm@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/