Re: [patch 00/15] Generic Mutex Subsystem

[Benjamin LaHaise]

On Mon, Dec 19, 2005 at 09:11:18PM +0100, Ingo Molnar wrote:
> i think we also need to look at the larger picture. If this really is a 
> bug that hid for years, it shows that the semaphore code is too complex 
> to be properly reviewed and improved. Hence even assuming that the mutex 
> code does not bring direct code advantages (which i'm disputing :-), the 
> mutex code is far simpler and thus easier to improve. We humans have a 
> given number of neurons, which form a hard limit :) In fact it's the 
> mutex code that made it apparent that there's something wrong with 
> semaphores.

True, but then the original semaphores weren't designed with fairness in 
mind so much as being able to operate quickly.  The commodity SMP hardware 
that we have today has significantly different characteristics than the 
first dual Pentium I used.  I think there is significant room for improving 
the implementation while still making it as tight and lean as possible.  To 
that end, adding state diagrams that make it easier to visualise what is 
going on would be a big help.  With that in place, it will be easier to 
provide optimized fast paths with understandable logic. 

> Just look at the semaphore implementations of various architectures, 
> it's a quite colorful and inconsistent mix. Can you imagine adding 
> deadlock debugging to each of them?

Agreed.

		-ben
-- 
"You know, I've seen some crystals do some pretty trippy shit, man."
Don't Email: <dont@xxxxxxxxx>.
-
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/