Re: volatile shared memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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]

It says "Microsoft Specific" ... "End Microsoft Specific" for
a reason, y'know.

See Volatile: Almost Useless for Multi-Threaded Programming


[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google