This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: volatile shared memory
Jeffrey Walton <noloader@gmail.com> writes:
> On Fri, Mar 16, 2012 at 12:21 AM, Ian Lance Taylor <iant@google.com> wrote:
>
>> 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).
Section 6.7.3, paragraph 6
An object that has volatile-qualified type may be modified in ways
unknown to the implementation or have other unknown side effects.
Therefore any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine,
as described in 5.1.2.3. Furthermore, at every sequence point the
value last stored in the object shall agree with that prescribed by
the abstract machine, except as modified by the unknown factors
mentioned previously.(114) What constitutes an access to an object
that has volatile-qualified type is implementation-defined.
Footnote 114 (non-normative):
(114) A volatile declaration may be used to describe an object
corresponding to a memory-mapped input/output port or an object
accessed by an asynchronously interrupting function. Actions on
objects so declared shall not be "optimized out" by an
implementation or reordered except as permitted by the rules for
evaluating expressions.
> 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.
That is a choice made by Microsoft (in my opinion, an unfortunate one).
You will note that all the relevant docs are in a section labelled
"Microsoft Specific." The important addition that Microsoft is making
is that writes to a volatile object have release semantics and reads of
a volatile object have acquire semantics. That is not in the language
standard.
Ian