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

[Nicolas Pitre]

On Thu, 22 Dec 2005, Ingo Molnar wrote:

> The discussion was not about ARMv5 at all. The discussion was about the 
> claim that 'ARMv6 is somehow magical that it needs its own stuff'. No it 
> isnt magical, it's a sane CPU that can implement a sane 
> atomic_dec_return(), or even better, a sane atomic_*_call_if_*() 
> primitive. Or whatever primitive we end up having - i dont mind if it's 
> called __mutex_whatever, as long as it has a _well defined_ meaning.

I'd like to point out that, while atomic_dec_call_if_* is really nice on 
i386, it is probably only good for i386 since no other architecture 
will be able to provide a better implementation than what can be done 
with atomic_dec_return() anyway.  Yet that IMHO overloaded 
atomic_dec_call_if_* stuff appears in core code.

But like for i386, those other architectures might be able to do some 
other tricks to achieve the same needed semantics.  My ARMv6 is one of 
them (and no it doesn't strictly follows the semantics of 
atomic_dec_call_if_*).  Are you willing to add more #if 
defined(CONFIG_MUTEX_FOO_ALGO) in the core code as time goes by?  I hope 
not.

> what i _DONT_ want is some over-opaque per-arch thing that will again 
> escallate into the same situation as semaphores: 23 different 
> implementations nobody is able to change at once, nobody is able to add 
> features or debugging to, and by today there's probably is no single 
> person on this planet who knows all 23 of them to begin with.

I agree completely with you.  But what I don't want is core code 
needlessly restricting architecture specific implementation for short 
and well defined fast paths.  Maybe that's where we must agree upon: a 
well defined fast path helper for mutexes?


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