Re: [PATCH] Replace completions with semaphores

[Ingo Molnar]

* Matthew Wilcox <matthew@xxxxxx> 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
--
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/