On 03/16/2012 01:14 PM, Jeffrey Walton wrote: > 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. > > [1] http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.90).aspx It says "Microsoft Specific" ... "End Microsoft Specific" for a reason, y'know. See Volatile: Almost Useless for Multi-Threaded Programming http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2016.html Andrew.
