Re: Should I use mutex in this context?
On Thu, 30 Oct 2008 08:45:04 -0400, Tommy <tommy767@gmail.com> wrote:
Interesting.
I did a very quick small test of VC8 (/Og vs /Od) just comparing the
op codes for the stated example:
int PoorManSwitch = 0;
void proc()
{
while(!PoorManSwitch) {
printf(".");
Sleep(500);
}
}
and comparing the non optimize compile vs the optimized compile, I can
see where the op code logic does change, to one where it is a
effectively a while {} loop:
:again
if (X) goto :exit
....
goto :again
:exit
to one that emulates a do while with reduce OP code set.
if (X) goto :exit
:again
....
if (X) go goto :again
:exit
The key though, is that it retains the original logic. The end result
is the same, the optimization is transparent.
I'm not going to reiterate everything Ulrich said in his reply to you,
which I suggest you read carefully. Instead, I will focus on what I said
earlier about "reachability". Given the fragment you presented, the
compiler cannot prove the global PoorManSwitch isn't used by printf or
Sleep (or functions they may call), which is what I was talking about in my
last message; therefore, it's going to have to read it each time around. If
you re-read my last message to you, you'll see that's exactly what I told
you in my first paragraph. Re-read my second paragraph to understand why
this helps provide correct behavior for operations such as mutex
lock/unlock as well.
Concerning the structure of the loop at the assembly level: I haven't
discussed that at all. The compiler is free to restructure the loop to make
it more efficient as long as it (the compiler) obeys C++ language rules. In
a nutshell, it can't do anything that alters the observable behavior of the
abstract machine that is the C++ execution model.
I am still not convince that an an compiler designer (which I have
experience in), is going to alter, in non-transparent ways, the
fundamental logic of application designers. At the very least, their
ought to be a warning of such a drastic change in application logic.
If you read compiler design books, much attention is paid to constraints on
optimizations, i.e., conditions that prevent them from being applied. These
constraints tend to be inherent to the algorithms behind the optimizations.
I agree with you that I can see how this can cause problems if it does
change the logic without throwing in other blind considerations
auto-magically.
But overall, I don't see this as any different with how a compiler
translates a switch statement with unordered case values to one that
is ordered or any other optimization - the definition of optimization
is to "enhance" what was provided generally in terms of speed or
reduce code, not change the end results or adding new entry or exit
points by altering logic.
My whole point is that application designers should not be concern
about these things. So I that is why I say I really really really,
really, hope this is not true. It means code has to be massively
reviewed with compiler level OP CODE considerations that may beyond
the pay level of these programmers.
Everyone agrees with what you're saying WRT stupid optimizations like VC's
defunct /Oa ("assumg no aliasing"), which was impossible to use in real
programs. But you're still missing the points everyone else is making. :)
--
Doug Harrison
Visual C++ MVP