Re: C++ Threads, what's the status quo?
Edward Rosten skrev:
Mirek Fidler wrote:
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
[snip reordering]
It looks like from this that y is global. If Lock() and Unlock() depend
on y, then the compiler couldn't reorder the bits of Lock() an Unlock()
depending on y. If the code for Lock() and Unlock() is not visible (eg
in a different translational unit), then how can the compiler reorder
the function calls?
Whether it is in a different translation unit or not does not really
matter. Global optimisation is possible, so assume that the compiler
can see what happens inside Lock and Unlock.
If Lock and Unlock are "external" function (e.g. calls to the operating
system), the compiler has every right to assume the function knows
nothing about y - at least if the adress of y is never given to the OS.
Note, I'm not claiming that threading is defined. I'm just disputing
this one particular example.
You could probably construct it more carefully, eg by saying that y not
visible outside the translational unit, and &y is never assigned to a
pointer of Shared* which is visible outside the translational unit.
I agree that there are lots of situations where the compiler could not
legally do the reordering.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]