lkml.org 
[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8
On Fri, Oct 22 2004, Ingo Molnar wrote:
>
> * Jens Axboe <axboe@suse.de> wrote:
>
> > It has to go, why? Because your deadlock detection breaks? Doesn't
> > seem a very strong reason to me at all, sorry.
>
> no, this is no reason at all. I'm really sorry this issue came up in
> this context because now people appear to be arguing this as some sort
> of policy issue, implying that is somehow improper to use mutexes
> instead of completions, which it clearly is _not_. I very much wanted to
> avoid this particular type of flamewar :-)
>
> Using mutexes for completion purposes is perfectly fine kernel code.
> Full stop.
>
> Using completions instead of mutexes in certain cases has some minor
> advantages for two simple reasons: it's slighly faster and it's also
> more readable.
>
> here's an example: initially i made the scheduler's migration logic use
> semaphores in that fashion and Linus made me change it to completions,
> because, and i quote Linus here:
>
> [...]
> Btw, should you not use completions here?
>
> Completions are optimized for the sleep (ie contention) case, while
> semaphores are optimized for the non-contention case. It also makes
> more "sense" from a conceptual angle (you're waiting for something to
> complete, not asking for an exclusive thing).
> [...]
>
> and i have to say the migration code did become cleaner. To signal some
> sort of event it's a more intuitive _symbol_ _name_ to use 'complete()'
> and 'wait_for_completion()' than to use 'up()' and 'down()'.
>
> [ If you truly do not agree with this contention then please just look
> at one simple conversion we did and check out the previous and the new
> logic, by reading the full previous code and the full resulting code. I
> do believe that if anyone at that point still thinks that the
> semaphore-based code is just as readable (in that context!) as the
> completion-based code that then his brains are not made of neurons but
> silicon :) ]

I fully agree with everything in your mail so far. What annoyed me is
some people advocating their changes under the false pretense that
existing use was broken, which it isn't.

completions _do_ make cleaner code for the intended case. But your
writing above is very clear and already explains that very well.

Lets put the issue to rest and get back to more productive work!

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.571 / U:16.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site