On Wed, Aug 28, 2002 at 10:59:36AM -0600, Tom Bradley wrote:
> > So volatile by itself gives nothing. In kernel you have to use barrier()
> Not True. volatille is very usefull. 'jiffies' are volatile, and many
> status registers variables for devices are volatile. Volatile means 'don't
> trust the cached value, reread it.' Any variable that changes very fast or
> very often should be volatile. The barrier() functions are used for
> syncing caches on SMP boxes, I believe they do nothing on UP boxes, not
> positive on this though.
Yes, I know they are there. But many other one would expect volatile are
not. The barrier is defined in include/linux/kernel.h to be
__asm__ __volatile__ ("": : :"memory")
so it IS an optimization barrier. Always and ever. It depends on what
you are doing. If you have one variable that shouldn't be kept in
registers, then volatile is appropriate. If you need to force content of
structure to memory, you use barrier() (actually locks are barriers, so
you almost never need barrier() explicitely).
Having actually looked up the definitions, I have to correct myself - to
enforce CPU cache coherency you need mb() macro.
Note that all code may be run SMP and definitely must be writen for SMP
so every variable where coherency is really required must be either
atomic_t or locked and then volatile is superfluous. Outside arch
specific code one must bear in mind, that even store and fetch
operations are not always atomic (eg storing constant on sparc).
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
