Re: [PATCH] doc: volatile considered evil

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan Cox wrote:
It's still ambiguous. A much more explicit title that nobody could argue with would be "do not use the 'volatile' keyword as a type qualifier for an object."


Except when you do. The kernel uses the C volatile in various places
itself for specific good reasons (and some for historical bad ones)

Perhaps a closer summary would be

Do Not Use Volatile
-------------------

1.	volatile is not a locking mechanism

Volatile does not define sufficiently sane or strong semantics for
locking. The kernel has proper locking mechanisms which also act as
compiler fetch/store barriers and where neccessary hardware barriers for
SMP systems. The kernel knows about all the corner cases, you probably
don't.

2.	volatile is not needed for mmio space

I/O memory access are done via readb/writeb and friends. They deal with
volatility themselves so you don't have to. They may nor may not use
volatile internally to their implementation, but that is none of your
business.

3.	volatile is not atomic

Using volatile does not guarantee atomic behaviour. This often requires
special instructions or code sequences too. We have atomic_t and the
atomic_* operators for this.

4.	volatile is not a store or read barrier

Using volatile is not always sufficient to order accesses on SMP or to
ensure things execute in the order expected. Instead the kernel provides
a set of barrier operations which have clearly defined semantics on all
systems. Make use of rmb, wmb, barrier, smp_wmb etc instead

When Might You Need volatile ?
------------------------------

When you are implementing the locking primitives on a new platform. When
you are implementing the I/O and atomic prmitives on a new platform. Also
in inline gcc assembler where "volatile" is used for subtly different
purposes.

Is there a good reason for using volatile in atomic/locking primitives?
AFAIKS there is not.

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux