Re: [PATCH 1/12]: MUTEX: Implement mutexes

[David Howells <dhowells@redhat.com>]

Linus Torvalds <torvalds@osdl.org> 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		    -> DEFINE_MUTEX
	  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.

David