Re: Should I use mutex in this context?
Tommy wrote:
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:
Try changing the
int PoorManSwitch = 0;
to
static int PoorManSwitch = 0;
Further, remove both the printf() and the Sleep(), both of which the
compiler can't easily know that they don't modify the flag.
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.
The mentioned logic doesn't alter the fundamental logic of application
designers. Compare that to the other example:
for( i=0; i!=x*y*42; ++i)
is optimized to
int __expr = x*y*42;
for( i=0; i!=__expr; ++i)
when it can be proven that neither x nor y change inside the loop's body.
This is the same as the while(!PoorManSwitch) above. An expression that
provably doesn't change inside the loop is assumed to be constant and its
computation is performed just once.
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.
When you write code that is based on unjustified assumptions, aka unportable
code or undefined behaviour, you effectively have to accept that moving it
to a different environment might break it. The operation of C code is
pretty well-defined, and based on those definitions, people write
optimisers.
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.
I beg to differ.
1. Assuming everything can change everywhere would effectively make
registers worthless, since you must load values from memory over and over
again. In fact even the simple assertion x==x couldn't be reasonably
optimised out, since something somewhere might change the value of x
between the two load instructions.
2. These problems only arise when data is shared between concurrently
running processes, so it only affects multithreading and IO. Both of these
areas are not and have never been the field of Joe Random Hacker but rather
require quite some care.
3. Looking at your example above, you didn't even reduce the scope of the
variable to the smallest possible scope (missing static). So, in many cases
these optimisations don't apply and so the sloppily-written multithreaded
code survives by chance. The very few cases that it crashes (maybe once a
day) don't matter either, unless it is really critical, because people
generally take it as granted that they have to reboot a computer now and
then or that they have to restart an application now and then.
Nevertheless, if start looking for bad C or C++ code, there are no end to
it. Add looking for bad multithreading code (in probably any language
except e.g. Erlang which was explicitly designed for it) and you will find
even more.
Uli
[snipped useless fullquote]
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932