Re: C++ Threads, what's the status quo?
Edward Rosten 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?
Global optimizers are not so uncommon today. Just consider that
y_lock.Lock() is a short function in "lock.c" which is not visible in
the above code, it still might be visible to the global optimizer. It
could still inline the code, and still change the order.
The next question would be "what if y_lock is part of a binary library
that is linked to the code", but I don't think that C++ really defines
what this is and forbids "global optimization" in this area.
The problem is really what James already said above: There is not yet
a contract a C++ compiler has to fulfill you could depend on.
Still, in practical applications, you can write multithreaded code that
works on a set of "well-behaived" compilers, just that this type of
well-ness (uhm) is not covered by any standard. That is the problem, you
need to check yourself.
So long,
Thomas
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]