Re: Threading issue in next standard
wkaras@yahoo.com wrote:
kanze wrote:
wkaras@yahoo.com wrote:
kanze wrote:
Chris Thomasson wrote:
<wkaras@yahoo.com> wrote in message
It seems that you (both) are interpreting "observable
reads/writes" to be the same as "all reads/writes". Again let
me repeat, by observable read/write I mean the equivalent of a
read or a write of a volatile variable.
I was. Now that I think about it, I think what Chris was
objecting to is that this "observability" be bound to the type
of the object; typically, what is needed in a multithreaded
context is an explicitly induced point in the program where all
previous writes (regardless of the target type) become visible
(before any of the following writes become visible).
Seems like overkill.
It is. But you generally do need synchronization accross a set
of accesses, and not a single access.
In fact, my own proposal could be
made more flexible:
namespace std
{
template <unsigned seq_id>
struct seq
{
template <typename T>
void observable_read(const T &);
template <typename T>
void observable_write<const T &);
};
template <typename T>
void observable_read(const T &x)
{ seq<0>::observable_read(x); }
template <typename T>
void observable_write<const T &);
{ seq<0>::observable_write(x); }
// ...
using namespace std;
// ...
a = 5;
seq<1>::observable_write(a);
a_ready = true;
seq<1>::observable_write(a_ready);
b = 5;
seq<2>::observable_write(b);
b_ready = true;
seq<2>::observable_write(b_ready);
In this example, the observable write to a could be reordered
to follow the observable write to b_ready, as long as
the observable write to a_ready still followed the one
to a.
There may not currently be any CPU architecture that
could take advantage of this amount of flexibility. But
the intent of the observable reads/writes is more clear,
and perhaps the code is more future safe.
This goes along somewhat with what Alan spoke of;
synchronization requests which affect sets of variables, rather
than all the variables (or just one access).
As you say, it won't buy you anything with most modern general
purpose machines today. And it introduces a lot of extra
complexity, for which we have little existing practice to base
our ideas on.
I think that Chris and I agree that volatile is not really
relevant with regards to multithreading. There is a proposal by
Microsoft to give more teeth to volatile. I'm not totally
against the proposal, as I think it goes in the direction of the
original intent of volatile. But I don't think that the
proposal will give volatile any more real relevance with regards
to multithreading. What you usually need in multithreading is a
sequencing guarantee---that (all) preceding writes will become
visible to all observers before any of the following writes.
(Note that this generally implies some sequencing actions on the
part of the observers as well.)
Wasn't the orginal intent of volatile to allow effective
interfacing with memory-mapped peripherals?
That's my understanding of it.
How could an implementation of volatile that worked properly
with memory-mapped peripherals (in the general case where
read/write order mattered) not work properly for inter-thread
data passing.
The implementation of volatile in Sun CC (and in g++ for Sparc
under Solaris) doesn't work properly for memory-mapped
peripherals:-). (At least not formally. I suspect that what
actually happens is that the hardware recognizes the address as
one of a memory mapped peripheral, and does some synchronization
on its own, even if the Sparc architecture standard doesn't
require it.)
Even if it did, however, volatile imposes an absolute ordering
on all accesses to everything that is declared volatile. Which
is only enough if you declare almost everything volatile. And
then, it is far too much, imposing an enormous performance
penalty.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 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++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]