Re: [PATCH] doc: volatile considered evil

Nick Piggin
2007-05-09T09:27:17Z

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.