lkml.org 
[lkml]   [2006]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] spinlocks: remove 'volatile'

* linux-os (Dick Johnson) <linux-os@analogic.com> wrote:

> >> Now Linus declares that instead of declaring an object volatile
> >> so that it is actually accessed every time it is referenced, he wants
> >> to use a GNU-ism with assembly that tells the compiler to re-read
> >> __every__ variable existing im memory, instead of just one. Go figure!
> >
> > Actually, it's not just me.
> >
> > Read things like the Intel CPU documentation.
> >
> > IT IS ACTIVELY WRONG to busy-loop on a variable. It will make the CPU
> > potentially over-heat, causing degreaded performance, and you're simply
> > not supposed to do it.
>
> This is a bait and switch argument. [...]

how could it possibly be? Linus has simply replied to your point:

> > > If I have some code that does:
> > >
> > > extern int spinner;
> > >
> > > funct(){
> > > while(spinner)
> > > ;
> > >
> > > The 'C' compiler has no choice but to actually make that memory
> > > access and read the variable [...]

Linus observed that the only possible purpose of the code you cited,
busy-looping, makes no sense.

If you dont intend to busy-loop, why does the code above look like a
busy-loop, and what do you need the volatile keyword for?

> [...] In fact, your spin-lock code already inserts "rep nops" and I
> never implied that they should be removed. I said only that "volatile"
> still needs to be used, not some macro that tells the compiler that
> everything in memory probably got trashed. [...]

your position here does seem to make much sense to me, so please help me
understand it. You suggest that the assembly code should be left alone.
But then why do you need the volatile keyword to begin with?

> Well, in fact I do know what I'm talking about. Your bait-and-switch
> arguments just won't work with me.

you seem to be quite self-confident. That is a nice thing to have for
say a pro boxer, but it can be a disadvantage when dealing with a
complex OS. Just curious, if you turn out to be wrong will you apologize
for wasting Linus' (and others') time and for insulting him like that?
(Or is this a totally impossible scenario not even worth discussing?)

> > Repeat after me (or just shut up about things that you not only don't know
> > about, but are apparently not willing to even learn):
> >
> > "'volatile' is useless. The things it did 30 years ago are much
> > more complex these days, and need to be tied to much more
> > detailed rules that depend on the actual particular problem,
> > rather than one keyword to the compiler that doesn't actually
> > give enough information for the compiler to do anything useful"
> >
> > Comprende?

here Linus claims that 'volatile' is useless and that the use of
'volatile' is almost always a sign of bugs. That includes your
code-samples too. So a proper answer on a technical forum like lkml
would _not_ be to ignore Linus' point like you did, but to answer it
directly. There are a couple of ways to answer it:

- you could explain why your sample code _does_ make sense. That's a
powerful way of making your point and you'll sure see an answer
either rebutting your point or conceding the point.

- or if you know that it makes no sense (minor nit: in which case you
should have pointed that out when writing them) then you could either
correct it, or cite actual kernel code to which your point applies.

- an even better (and by far my most favorite) method of reply would be
if you sent an actual kernel patch (ontop of 2.6.18-rc1 plus my
volatile-removal patch) that implements your suggestions! That
would be a perfect way of making your point - one line of patch is
worth a thousand words.

Ingo
-
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: 2006-07-08 00:17    [from the cache]
©2003-2011 Jasper Spaans