Re: How to current close window while messages still in queue
On Thu, 6 Nov 2008 04:40:44 -0800, "David Ching"
<dc@remove-this.dcsoft.com> wrote:
"Doug Harrison [MVP]" <dsh@mvps.org> wrote in message
news:t0s4h4t8oggra5cfhd570nf511jlo85o1a@4ax.com...
You crack me up.
Ah c'mon. Can't you try to at least velcro that perpetual chip to your
shoulder before replying in that tone? Please?
Yawn. We've already had 3 examples of wasting our time. Let's not make
this thead the 4th.
Apology accepted. :)
It's not worth debating what the word "optimization"
means. I see your point about maintaining both the event and the bool, and
hopefully the OP will use the event if it is used elsewhere and the bool if
not. I have used the global variable several times over my career and never
once declared it volatile, and never once had it fail in widely deployed
scenarios. If the compiler did create an infinite loop, it certainly would
have been noticeable and reproducible, but it never happened. Maybe that
optimization is disabled by default, but that's why when others claim this
technique works, I tend to believe them. But thank you for the 'volatile'
tip. I'll use it from now on.
In the other thread, I explained why it often works when the bool is not
declared volatile. I also explained why declaring it volatile is necessary
to prevent certain compiler optimizations that may be possible in the
absence of volatile. In my previous message in this thread, I gave an
admittedly contrived example, but it would be trivially easy to make it
non-contrived to show that volatile is necessary for the technique to work.
There may be other very non-portable reasons to declare it volatile in
VC2005 and later, which I gave in the other thread.
In a nutshell, your non-volatile-using code worked because there were
sufficient opaque function calls preceding access to the non-volatile bool
to kill the compiler's analysis of the bool's usage. And that's really not
even a MT concern. It has more to do with function call nesting, such that
if the compiler can't prove the variable is not reachable from some
function call f(), it has to assume f() or some function it calls modifies
it. This is part of the reason that correct behavior for memory visibility
around calls to Windows wait/release synchronization functions sort of
falls out naturally WRT things like code motion around the calls. Because
the wait/release functions are opaque, the compiler must assume they affect
the observable behavior of the program, so NON-volatile variables
potentially accessible from the functions have to be flushed to memory
(with their expected values) for their possible use by those functions.
Internally, the wait/release functions have to use memory barriers as
necessary to ensure the hardware doesn't reorder things improperly.
However, if the compiler has sufficient knowledge of the source code and is
able to perform the necessary flow analysis to determine the non-volatile
variable isn't altered, things fall apart, and you need to declare it
volatile. (Or for a wait/release function, the compiler would have to mark
the function up to suppress optimizations, as we can't begin to require
volatile on top of synchronization.) Even using volatile may have problems
which I discussed in the other thread, which is why protecting variable
access with a mutex is the truly foolproof method. Even with the new VC2005
semantics, volatile doesn't have much use in MT programming, but the memory
barrier semantics do help the "volatile bool technique" continue to work on
machines like SMP Itaniums. I would bet $1 MS changed volatile in VC2005 so
that some poorly written MT code (perhaps a major customer or two) would
continue to kinda sorta work on the more exotic SMP machines.
--
Doug Harrison
Visual C++ MVP