Subj : Re: Return value from worker thred when the working thread must be suspend after calculation???
To   : comp.os.ms-windows.programmer.win32,microsoft.public.vc.language,comp.programming.threads
From : Alexander Grigoriev
Date : Wed Aug 31 2005 11:05 pm

Here is a classic example:

Suppose your main thread is waiting for some result from your worker thread. 
For example, it may want to enter a critical section currently owned by the 
workthread, or is waiting for the worker thread completion. At the same 
time, the worker thread is trying to access main thread's window. It will 
have to wait until the main thread is in message dispatching state, which 
won't happen because it's waiting, too.

"David W. Poole, Jr." <STKR!@microsoft.com> wrote in message 
news:cbr7h11ti4f8hv0i9212aej455lc8tneik@4ax.com...
> On Mon, 29 Aug 2005 22:14:25 -0700, "Alexander Grigoriev"
> <alegr@earthlink.net> was understood to have stated the following:
>
>>You should not access windows of the main thread from the secondary 
>>thread.
>>This may lead to deadlocks. Use PostMessage to communicate between 
>>threads.
>
> Ok, I'll buy using PostMessage() over SendMessage() to have a worker
> thread update the user interface as a safer alternative.
>
> Of personal interest though is how this can lead to a deadlock
> condition. In the applications where I utilize this technique, when a
> worker thread is initiated, the parameters are read from the
> appropriate controls, and the values are stuffed into a structure that
> is passed to the worker thread. Thus, the worker thread no longer
> requires any input from the user interface; it only needs to update
> the UI on occasion; say for progress information while the thread is
> active, and for parametric information upon the thread's completion.
> How can this lead to a deadlock, even with SendMessage(), as the
> worker thread never tries to obtain information from the user
> interface? There's never anything the worker thread is waiting on, and
> the user interface thread doesn't have any code other than the code
> that very quickly handles messages?
>
>

.