Sitsofe Wheeler wrote:
Henrik Austad wrote:
On Monday 15 September 2008 17:13:08 luca ellero wrote:
Why slock is not declared as "volatile" in the 2.6.25 kernel?
the section you refer to (volatile), was introduced in commit
fb1c8f93d869b34cacb8b8932e2b83d96a19d720 in sep. 2005.
volatile ensures that the variable stays in the memory, i.e. it is not
stored in any register for optimization.
From the allmighty K&R [p211]: "The purpose of volatile is to force an
implementation to suppress optimization that could otherwise occur.
For example, for a machine with memory-mapped input/output, a pointer
to a device register might be declared as a pointer to volatile, in
order to prevent the compiler from removing apparently redundant
references through the pointer"
As this is an SMP spinlock, having it in a local register is a bad
idea :-)
as to why it's not used any more, I'm not too sure, as it is used
(when you compile with the debug-spinlock on. Now, I'm not testing
this against 2.6.25.3, but in the normal linux-tree, there hasn't been
a change in spinlock_types_up.h since July 2007.
volatile use is a risky business. It only really makes sense when you
dealing with a single CPU and you are protecting yourself from DMA
hardware issues which might be caused by compiler optimisation (where
memory could be cached in a register as you said). volatile just says to
the compiler "don't do optimisation around this" (a simplification)
which can make for slow code. It can also help hide real issues. Linus
talks about it here: http://kerneltrap.org/Linux/Volatile_Superstition
and http://kerneltrap.org/node/14225 .
When you are in the SMP protecting data from other CPUs case (as implied
by it being an SMP spinlock) you have to use locks/memory barriers and
if you have those then why did you need volatile? It then won't matter
if the value made its way into a register because you won't read it will
make its way back before use...
Mmmmmh, it's not so easy like the author believe then!
Anyway, thanks everybody for the answers.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
