Re: [PATCH] doc: volatile considered evil

[Nick Piggin <nickpiggin@yahoo.com.au>]

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 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/