Re: volatile shared memory

[Andrew Haley <aph at redhat dot com>]

On 03/16/2012 01:14 PM, Jeffrey Walton wrote:
> On Fri, Mar 16, 2012 at 12:21 AM, Ian Lance Taylor <iant@google.com> wrote:
>> NightStrike <nightstrike@gmail.com> 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.