Subject: Re: [patch 00/15] Generic Mutex Subsystem
Newsgroups: gmane.linux.kernel
Date: 2005-12-19 20:11:18 GMT (3 years, 28 weeks, 1 day, 6 hours and 12 minutes ago)
* Benjamin LaHaise <bcrl <at> kvack.org> wrote: > > [ Oh. I'm looking at the semaphore code, and I realize that we have a > > "wake_up(&sem->wait)" in the __down() path because we had some race long > > ago that we fixed by band-aiding over it. Which means that we wake up > > sleepers that shouldn't be woken up. THAT may well be part of the > > performance problem.. The semaphores are really meant to wake up just > > one at a time, but because of that race hack they'll wake up _two_ at a > > time - once by up(), once by down(). > > > > That also destroys the fairness. Does anybody remember why it's that > > way? ] > > History? I think that code is very close to what was done in the > pre-SMP version of semaphores. It is certainly possible to get rid of > the separate sleepers -- parisc seems to have such an implementation. > It updates sem->count in the wakeup path of __down(). 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. we saw that with the genirq code, with the spinlock code, with the preempt code. Consolidation did not add anything drastiically new, but code consolidation _did_ make things more hackable, and improved the end result far more than a splintered set of implementations would have looked like. 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? Ingo