I would like to point out that the proposed rewording does not include
a
proper handling of volatile memory locations.

For example 1.10p12:
Following the reviewed 1.10p12, how is a program expected to read
correct values
from any volatile memory, when the value is modified by an external
agent?
And a minor issue with respect to the first note: ambiguity about
which side
effect is visible, is *not* necessarily due to a data race, albeit it
will
result in undefined behavior.

IMHO, the memory model should take volatile data into consideration,
because
1.9p6 requires an implementation to present a sequence of accesses to
volatile
data. This has been sufficiently solved for single-threaded programs,
but is
still left open for multi-threaded programs. Concurrent accesses and
the
uncertainty about when they exactly happen (1.9p13 states that access
to a
volatile memory location is completed once the initiating instruction
has
finished from the view of the issuing thread - not quite helpful in a
multi-threaded context, where instructions may appear reordered
elsewhere) such
(unambiguous) sequences cannot always be guaranteed. A proper memory
model
should find some clarifying words in how to serialize such accesses.

With kind regards

Wolf Lammen

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

wolf.lammen wrote:

> I would like to point out that the proposed rewording does not include
> a
> proper handling of volatile memory locations.
>
> For example 1.10p12:
> Following the reviewed 1.10p12, how is a program expected to read
> correct values
> from any volatile memory, when the value is modified by an external
> agent?

I don't think it is explicitly stated anywhere, but both the C and the
(current and proposed) C++ standards assume that accesses to volatile
memory, both by the program and by external agents, do not interleave.
This means that only full updates by the external agent would be seen by
the program (and vice-versa), resulting in correct values being read.

> And a minor issue with respect to the first note: ambiguity about
> which side
> effect is visible, is *not* necessarily due to a data race, albeit it
> will
> result in undefined behavior.
>
> IMHO, the memory model should take volatile data into consideration,
> because
> 1.9p6 requires an implementation to present a sequence of accesses to
> volatile
> data. This has been sufficiently solved for single-threaded programs,
> but is
> still left open for multi-threaded programs. Concurrent accesses and
> the
> uncertainty about when they exactly happen (1.9p13 states that access
> to a
> volatile memory location is completed once the initiating instruction
> has
> finished from the view of the issuing thread - not quite helpful in a
> multi-threaded context, where instructions may appear reordered
> elsewhere) such
> (unambiguous) sequences cannot always be guaranteed. A proper memory
> model
> should find some clarifying words in how to serialize such accesses.

I think you are misinterpreting 1.9/6. There is no requirement for a
single, unambiguous sequence of volatile accesses, because such a
sequence is generally impossible to give even for a single-threaded
application.

For example, this program already has multiple possible sequences for
the volatile accesses:
   volatile int a;
   volatile int b;
   int main()
   {
     int c = a + b;
   }

The sequence mentioned in 1.9/6 should be interpreted as the set of
orders of accesses to volatile objects and I/O calls as it can occur in
any possible execution sequence of the abstract machine.

As for the definition of when the side-effects of a volatile access are
considered complete, please remember that volatile is not and was never
intended for inter-thread communication.
One of the main reasons for the existence of volatile is to enable the
communication with (memory-mapped) external hardware. Access to such
hardware can have wide ranging effects, which is not known nor
detectable by the implementation. Additionally, it is not uncommon that
reading from such hardware, if that is at all possible, produces
additional physical effects and different values from what was last
written.

In the end, volatile is neither needed nor sufficient for inter-thread
communication. It exists for completely other reasons.

>
> With kind regards
>
> Wolf Lammen
>
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]