Re: [patch 0/9] mutex subsystem, -V4

[Arjan van de Ven <arjan@infradead.org>]

> >    * - only one task can hold the mutex at a time
> >    * - only the owner can unlock the mutex
> >    * - multiple unlocks are not permitted
> >    * - recursive locking is not permitted
> >    * - a mutex object must be initialized via the API
> >    * - a mutex object must not be initialized via memset or copying
> >    * - task may not exit with mutex held
> >    * - memory areas where held locks reside must not be freed
> 
> Pretty much all of that could be added to semaphores-when-used-as-mutexes. 
> Without introducing a whole new locking mechanism.

this is basically in direct conflict with what Linus has been asking
for.. "leave semaphore semantics alone".

I agree with Linus that if it has very different rules, it should have a
different name. 

> Ingo, there appear to be quite a few straw-man arguments here.  You're
> comparing a subsystem (semaphores) which obviously could do with a lot of
> fixing and enhancing with something new which has had a lot of recent
> feature work out into it.
> 
> I'd prefer to see mutexes compared with semaphores after you've put as much
> work into improving semaphores as you have into developing mutexes.

semaphores have had a lot of work for the last... 10 years. To me that
is a sign that maybe they're close to their limit already.

You keep saying 10 times "so please enhance semaphores to do this".
Semaphores have far more complex rules for the slowpath (mutex semantics
are simple because the number of wakers is always at most one, and if
you hold the lock, you KNOW nobody else can do another release under
you). Adding dual rules or other complexity to it doesn't sound too
compelling to me actually; they're highly tricky things already (just
look at the i386 ones.. that extra wakeup was there to plug a hole (at
least that is my empirical conclusion based on "we remove it it hangs"
behavior).

Having 2 sets of behaviors for the same primitive also sounds not good
to me to be honest, that's bound to explode stuff left and right all the
time.

I realize you're not looking forward to a gradual conversion; yet Linus
says he doesn't want a wholesale change either but wants it gradual.


-
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/