Re: [patch] spinlocks: remove 'volatile'

[Davide Libenzi <davidel@xmailserver.org>]

On Sat, 8 Jul 2006, J.A. Magallón wrote:

> On Fri, 7 Jul 2006 17:22:31 -0400, "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:
>
> > On Fri, 7 Jul 2006, Linus Torvalds wrote:
> >
> > > On Fri, 7 Jul 2006, linux-os (Dick Johnson) 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. The code was displayed to show
> > the compiler output, not an example of good coding practice.
>
> volatile means what it means, is usefull and is right. If it is used
> in kernel for other things apart from what it was designed for it is
> kernel or programmer responsibility. It does not mention nothing about
> locking.

(looking at your code ...)
I think you guys mixed the concepts about *if* a memory access happens 
(volatile), and *where* the memory access happens (barrier).
As far as kernel coding goes (or MT userspace), if you happen to care *if*
a memory access happens, you probably want to care even *where* the memory 
access happens. And modern CPUs and compilers do not respect the WYSIWYG 
property ;)
This is not always true (*if* -> *where*), but it's very frequent.
And using "volatile" can make your code work in some cases, and misbehave 
in others.
Can we now all move on to a more refreshing "C++ kernel rewrite" thread :)



- Davide