On Jan 1, 4:55 pm, "wolf.lammen" <wolf.lam...@googlemail.com> wrote:
> 1.10 paragraph 2 of N2800 C++ draft explicitly lists values that can
> be seen from threads. This list apparently does not cover some kind of
> volatile data (as hardware induced modifications). What implications
> has this restriction on access of volatile data from threads. Does it
> really mean, as I read it, certain kind of volatile objects are
> precluded from being accessed by threads?

Since a volatile object is one whose value can change asynchronously
with regard to the program's execution, I don't see how the number of
threads that a program might be running would change anything about
how that program accesses volatile objects. Because - whether a
program has one thread or many - a volatile variable's value can
change without regard to what any one of those threads is doing.
Therefore there seems little that would connect the two concepts
(multiple threads and volatility) to each other. In fact, I suspect
that the two concepts will interact with each other only very weakly
in the upcoming C++ Standard, if in fact they interact with each other
at all.

Of course, adding multiple thread support to C++ changes many things
about how a program manages its variables. But these changes apply to
both volatile and non-volatile variables alike.

Greg



--
[ 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                      ]

On 3 Jan., 10:11, Greg Herlihy <gre...@mac.com> wrote:
> Since a volatile object is one whose value can change asynchronously
> with regard to the program's execution, I don't see how the number of
> threads that a program might be running would change anything about
> how that program accesses volatile objects.

If you have more than one thread running, data races may be present.
You have to identify them to ensure your program does not expose
"undefined behaviour". Note that the wording of the thread model is
very unclear as far as volatile data is concerned. E.g., in addition
to the here mentioned paragraph 10.1/2, try to find a visible sequence
of side effects using 1.10/12. Do you see the problem? 1.10/12 stays
correct only, if volatile data is *always* of an atomic type!! The
model, as it is, imposes this restriction on the usage of
(asynchronous modifyable) volatile data in a multi-threaded program.
Note, that all these problems magically disappear in a single-threaded
program, because data races do not exist there.
So the number of threads *are* of importance (in the current draft)
wrt volatile data.

> Because - whether a
> program has one thread or many - a volatile variable's value can
> change without regard to what any one of those threads is doing.
> Therefore there seems little that would connect the two concepts
> (multiple threads and volatility) to each other. In fact, I suspect
> that the two concepts will interact with each other only very weakly
> in the upcoming C++ Standard, if in fact they interact with each other
> at all.

What makes me feel uncertain here, is that asynchronous changes in a
sense constitute a 'data race' in the relation of the program to its
outer world. So all the synchronization issues well-known from inter-
thread communication, are possibly present here as well, and might
require more rigorous handling. As for me, I don't have a clear view
right now. If you know more, I'd appreciate to be pointed to relevant
material.

> Of course, adding multiple thread support to C++ changes many things
> about how a program manages its variables. But these changes apply to
> both volatile and non-volatile variables alike.

If this is so, the wording of the model IMHO should reflect this.

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                      ]

On 2 Jan., 16:47, James Kanze <james.ka...@gmail.com> wrote:
> Still, I'd argue that we should add some extra text to the end
> of the paragraph.  Something like: "In addition, if the object
> has volatile type, the value visible to a thread may have been
> modified in some implementation defined manner externally to the
> program."  (Not sure of the exact wording, but I'm pretty sure
> that the "implementation defined" and the "externally to the
> program" belong in there somewhere.

Then (at least) 1.10/12 needs a fix as well. See my answer to Greg.

Wolf


--
[ 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                      ]

Hi,

It seems that the concept of volatile data is insufficiently embedded
in the current multi-threading model.

Access to volatile data is fundamental to observable behavior of
programs (1.9/6). However, what is perceived in reality, is affected
by latencies, often neither controlable nor visible to a program. So
the program model assumes access to volatile data to have been
completed the moment the program instruction requesting it completes
(1.9/13). That way, latency becomes a problem of the outside world,
and observable behavior of the abstract machine -- independent of
possible latency induced reorderings -- is tied to program execution
order. Note how section 1.9 carefully enforces program order (1.9/9
along with 1.9/14, 1.9/15 and 1.9/16) on accesses to volatile data,
such accomplishing a defined (observable) sequence in a single-
threaded program.

But concurrent world is different. Here, there is no single total
program order (two instructions may complete at exactly the same clock
cycle, for example). So accesses to volatile data may not be
serializable (of course, any hardware will ultimately serialize
accesses, but that doesn't matter for an abstract machine, see above),
and an observable sequence of them, as required by 1.9/6, need not
exist (not even when no two accesses to volatile data race). So the
multi-threaded model in 1.10 seems not fully comply to the single-
threaded model in 1.9.

Apart from this, the wording of 1.10/2 and 1.10/12 needs to be
revisited, since it covers asynchronously modified volatile data
insufffiently.

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                      ]

Hi,

1.10 paragraph 2 of N2800 C++ draft explicitly lists values that can
be seen from threads. This list apparently does not cover some kind of
volatile data (as hardware induced modifications). What implications
has this restriction on access of volatile data from threads. Does it
really mean, as I read it, certain kind of volatile objects are
precluded from being accessed by threads?
I could not find anything related to this in this group or comp.lang.c+
+.moderated.

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                      ]

On Jan 2, 1:55 am, "wolf.lammen" <wolf.lam...@googlemail.com> wrote:

> 1.10 paragraph 2 of N2800 C++ draft explicitly lists values
> that can be seen from threads. This list apparently does not
> cover some kind of volatile data (as hardware induced
> modifications). What implications has this restriction on
> access of volatile data from threads. Does it really mean, as
> I read it, certain kind of volatile objects are precluded from
> being accessed by threads?

I'm pretty sure that that's not the intent.  Volatile isn't used
for communication between threads, but there's certainly not (or
shouldn't be) any problem using a volatile variable in a single
thread, or even between threads, if the other rules are met.

On the other hand, the values that you might see are largely
implementation dependent.  The Sparc system documentation, for
example, makes it very clear that in order to access an up to
date value from a hardware register (memory mapped IO), a membar
instruction must be used; accessing through a volatile qualified
lvalue doesn't cause a membar instruction to be generated,
however; I don't know how these compilers define "what
constitutes and access" to a volatile object, but it doesn't
look like it's anything useful.

Still, I'd argue that we should add some extra text to the end
of the paragraph.  Something like: "In addition, if the object
has volatile type, the value visible to a thread may have been
modified in some implementation defined manner externally to the
program."  (Not sure of the exact wording, but I'm pretty sure
that the "implementation defined" and the "externally to the
program" belong in there somewhere.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


--
[ 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                      ]