Re: C++ Threads, what's the status quo?
Le Chaud Lapin wrote:
Mirek Fidler wrote:
Ahh... I guess you should seriously reconsider the issue.
Recommended reading is e.g. google: "why double checked guard does not
work".
Just for starters, if you have
Shared y;
Mutex y_lock;
void fn() {
y_lock.Lock();
y = 10;
y_lock.Unlock();
}
nothing in C++ standard prevents C++ compiler to generate machine code
equivalent to
void fn() {
y = 10;
y_lock.Lock();
y_lock.Unlock();
}
Are you saying that the C++ standard does not prescribe sequential
execution of statements in a single-threaded program?
It most certainly doesn't. Doing so simply wouldn't be
acceptable because of the performance cost. All C++ compilers,
and all C compilers I used before, have done code movement in
some cases. It's a standard optimization technique.
If that is the case, then I could write a single-threaded application
that would not behave as a programmer would expect using an example
very similar to the one you gave.
The standard defines the semantics of a program, in terms of its
observable behavior. A compiler can do anything it wishes, as
long as those semantics are respected. And those semantics are
only defined in the context of a single thread.
Note too that the reordering can also be done by hardware, even
if the compiler respects the semantics exactly. To prevent
this, you have to use special instructions. And compilers don't
introduce these instructions everywhere, simply because that
would slow things down too much.
In practice, this is nothing new, and nothing particular to C++.
IBM's Fortran H was reordering accesses way back in the late
1960's.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]