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.