Messages in this thread | | | Date | Mon, 14 Apr 2008 17:39:28 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] Replace completions with semaphores |
| |
* Matthew Wilcox <matthew@wil.cx> wrote:
> On Sun, Apr 13, 2008 at 09:08:33AM +0200, Ingo Molnar wrote: > > but semaphores will be _removed_, _completely_. Rewriting them in > > generic C code is just the first step towards that - it consolidates all > > the myriads of semaphore implementations that Linux has spread out. > > I think you're dreaming. [...]
no, i'm hoping for a simpler and thus more maintainable kernel.
> [...] We have 11 places in the tree that currently demand to use a > counting semaphore (with 'n' plausibly greater than 1). [...]
which ones exactly are these places that demand the use of a counting semaphore? I cannot think of a single place where it's the best choice, let alone one where it's the only choice.
And if there's just 5 isolated places in the kernel that would need a different locking primitive then i say that it's probably not worth it. Locking is at the center of every data structure and the clarity and simplicity of basic data structure operations is paramount IMHO.
Semaphores are i think a relic from the days when people thought that parallelism can be best achieved via complexity and rafinery of locking primitives - regardless of how usable and debuggable those APIs end up to be. Today we can go extremely parallel with very simple and robust primitives.
> [...] If we remove the facility, these places are going to invent > their own weird locking schemes.
i'm not worried about weird locking anymore - lockdep tends to expose them rather nicely and the lack of lockdep coverage for open-coded locking schemes tends to be a barrier as well. The past 2 years have shown that people want lockdep coverage for just about everything where it can be applied: workqueues, special locks, etc. (there's even questions about whether it could be extended to cover user-space locks.)
Ingo
| |