On Fri, Jul 25, 2003 at 04:58:35PM +0300, Juhana Sadeharju wrote: You gave the answer yourself: what is an 'apparent volatile' variable ? Almost any algorithm you may think of will be wrong 50% of the time. Your code is not a good example to show it should be possible to detect 'apparently volatile' data -- it's too simple. If you would have written to num [1] somewhere, would that make it less volatile ? You have a complete application in your mind, and things may seem clear, but the only thing your compiler sees is the single file it is compiling. 99.99% of all code written does not involve volatile data, most coders are not even aware that it exists, so it is reasonable for a language or compiler to assume that data is not volatile unless this is explicitly stated. This has been so even before the 'volatile' keyword was introduced in C. Before that time the only safe way to access volatile data was by using an external function to do it. It's not a big deal, if you know your data can be modified in ways not visible in the source code, use 'volatile'. It becomes a habit. -- FA

On Fri, 2003-07-25 at 16:58, Juhana Sadeharju wrote: There is reason why optimizer chooses to keep variables in CPU registers instead of flushing all the stuff at every assignment operator. With current processors you would get _really_ slow code without careful optimizer use of register variables (btw. x86 arch has way too few registers available, compared to RISCs) and to be careful _not_ to trash the cache. Few points to keep in mind: 1) compiler doesn't know anything about threads (except those which support OpenMP), so any non-volatile variable is potential register variable which update time to other threads is unspecified. All inter-thread variables should be defined volatile. 2) compiler doesn't know anything about processes or IPC, so same as above. All inter-process variables should be defined volatile. 3) on SMP systems each CPU still has it's own dcache -- Jussi Laako <jussi.laako(a)pp.inet.fi>