Re: Closing modeless dialogs
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:ej4bmWQhIHA.944@TK2MSFTNGP05.phx.gbl...
Torsten Hensel wrote:
David Wilkinson wrote:
Always use PostMessage() (or SendMessage() if you are careful) to
transmit information back to the main thread. This changes the thread
context back to that of the main thread.
I know this, but I don't know why. Currently I'm simply calling a member
function of my dialog called SetText from the worker thread, and
everything works fine. Why is this a problem? Race conditions cannot
occur in my case, since nothing changes the dialog except my worker
thread. The dialog simply waits for messages, but no messages are sent to
the dialog. Can you explain what problems can occur in this case?
Actually, message *are* sent to the dialog, by Windows, for example if the
dialog is moved, minimized, restored, covered then uncovered by other
windows, if the machine is shutting downs, etc., etc. In order to maintain
the multiple windows "illusion" on the screen that Windows depends upon the
dialog must promptly process messages that are sent by the operating system.
That is the core reason why you are using a worker thread instead of
blocking your main thread with lengthy operations.
Calls from a worker thread that change the dialog or its controls are not
simple "calls." Under the hood you can see that they all become SendMessage
calls. What really happens is that the SendMessage call suspends your
calling thread and waits for the main thread to process the sent message and
return. (A window can only be updated in the context of the thread that
created it.)
This introduces three problems. The first is simply that by suspending your
thread for every window update you are losing most of the benefit of
multithreading. Every window update call becomes a thread synchronization
and rescheduling bottleneck. Poor performance.
The second problem is that if the main thead does not process the sent
message you have a deadlock. This occurs if the main thread is stopped,
perhaps waiting for the worker thread to terminate. (One of the difficult
aspects of multithreading is properly sequencing the program shutdown.)
The third problem is somewhat ill-defined: MFC is not designed to support
out-of-thread access to CWnd objects, and in fact it goes to some trouble to
forbid such access in many (but not all) cases. Yes, SetText might happen
to work because it is such a simple call, but you are treading in "not
designed for this" waters, breaking the rules laid down by the MFC
designers. In effect, you are reentering MFC code that was not designed to
be reentered. It is best to avoid that because the authors have issued a
clear warning that it is not guaranteed to work with future changes.
--
Scott McPhillips [VC++ MVP]