Yawn. We've already had 3 examples of wasting our time. Let's not make
this thead the 4th. It's not worth debating what the word "optimization"
means. I see your point about maintaining both the event and the bool, and
not. I have used the global variable several times over my career and never
scenarios. If the compiler did create an infinite loop, it certainly would
have been noticeable and reproducible, but it never happened. Maybe that
technique works, I tend to believe them. But thank you for the 'volatile'
tip. I'll use it from now on.
With all of your knowledge and precision, you don't see
reading a global variable is more efficient than calling a function?
Of course it's more efficient. That's not the point. The point is what I
said in my message.
Especially when WaitForSingleObject() relinquishes the quantum of the time
slice (well, with a timeout of 0, I think it still does); therefore, there
is no way to argue that replacing this code with a memory read is not an
optimization.
I said, "That's not so much an optimization as it is an alternative
technique." That's not a denial it's an optimization; it's as assertion
that it's another technique with its own set of rules and trade-offs, one
of which I went on to mention directly afterwards, that may have
ramifications for the rest of the (unseen) code. You may be right about
the
time-slice issue; I have no idea. But keep in mind the OP had read a
database recordset and was passing row data over PostMessage using
dynamically allocated objects in a MT program. If this would cause it to
ping-pong, i.e. reduce it to single-threaded behavior, that would be a
problem, but I'm not aware that it occurs, and I would be surprised if it
did. It's worth investigating if you're really that interested in
demonstrating your optimization.
The OP is not using the event anywhere else, and even if he
were, how does using it here justify the decreased efficiency?
How do you know the OP is not using the event anywhere else? My assumption
is that he has a reason for using an event, not that he doesn't know any
better. If he is using it with WFMO, then your optimization would require
him to maintain both the bool and the event. If you can prove that's worth
doing in some high performance setting, great, but absent any evidence,
I'm
going to assume it's undesirable redundancy. The point you seem to have
missed is that if the event is being used elsewhere, say, in WFMO, you
can't just set the bool. You gotta set the event as well, so you have dual
mechanisms, and I hope my tiny paragraph that "cracked you up" now makes
sense to you:
That's not so much an optimization as it is an alternative technique. To
see what I mean, consider that the OP may be using the event elsewhere in
WFMO calls. If he is, he should continue using the event everywhere.
To me, that's a totally innocent, totally technical comment with no evil
undertones intended. I thought it went without saying that if he is not
using WFMO, or otherwise making sophisticated use of the event, that using
the /volatile/ bool approach might be acceptable, modulo its own set of
caveats.
Thanks, the thread is at
http://groups.google.com/group/microsoft.public.vc.language/browse_thread/thread/f092254ec9555669).
I'm not sure you proved the point that with VC2005 on x86 that there would
actually be a problem if you DIDN'T use volatile, but it's good to use
volatile just in case.
In those messages, I talked about the volatile bool method in depth and
the
fact that omitting the volatile qualifier puts you at the mercy of the
optimizer vis-a-vis what the compiler can determine about the usage of the
bool. It's another one of those "robustness" vs. "randomness" things. I
did
prove what you doubt in my reply to Gerard O'Brien, which I'll repost
here:
<q>
That's the essential wrong idea you have. You cannot regard this program
as
anything but an infinite loop:
int x = 1;
int main()
{
while (x) {}
}
1. Absent the declaration of x as volatile, the compiler is free to assume
no one modifies x asynchronously.
2. Absent any code that modifies x in the loop, the compiler is free to
conclude that the loop does not modify x.
Put (1) and (2) together, and it's clear that the compiler is free to
evaluate x once and use its cached value until something invalidates what
it knows about x.
</q>
If you compile my example program with optimizations to machine code,
it'll
be an infinite loop, and setting x to 0 in some other translation unit
ain't gonna get you out of it. Making x volatile will fix it.
--
Doug Harrison
Visual C++ MVP