On Fri, Mar 16, 2012 at 12:21 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > NightStrike <nightstrike@xxxxxxxxx> writes: > >> If I am interacting with shared memory, gcc doesn't know if another >> process changes values. This creates issues for optimization. I know >> that "volatile" can help address this, but it winds up causing a giant >> mess of other problems (like, for instance, I can't pass a volatile >> into memcpy.. or pretty much anything else from the standard >> libraries). > > No, volatile can not address this. This is not what the volatile > qualifier is for. The volatile qualifier is designed for working with > memory mapped hardware. It is not designed for multi-processor shared > memory. If a program is not multi-processor safe, then adding volatile > will never make it multi-processor safe. > > This is because the issues related to making code multi-processor safe > are related to memory barriers and memory cache behaviour. Adding a > volatile qualifier will not change the program's behaviour with respect > to either. Would you be able to paste the verbiage from the C or C++ standard? (I don't have a coy of the standard). The reason I ask is Microsoft appears to have a different interpretation of the qualifier [1], and does not limit 'volatile' to memory mapped hardware. Jeff [1] http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.90).aspx
