Re: SendMessage (in secondary thread) freezes application GUI thre

Thanks for that Paul.

This is what I actually see in my log:

Thread B: Before Sending Message
UI: Received Message, processing now
UI: Finished processing, returning
Thread B: Returned from Sending Message
..
.. (The above gets repeated a random amount of times...)
..
Thread B: Before Sending Message
****************************** And this is the point the application GUI
hangs at.

Putitng together what you and Michael have taught me, my guess is that the
main application is deadlocked, as to why it's deadlocked, I was
investigation the possibility of another message being sent at the same time,
causing the UI to freeze. But with what you've just replied, it seems not
possible... each message will be processed in turn. What's probably happening
is that the message is getting sent, but the UI thread is processing some
other message and deadlocking on that message... and the OS is un-deadlocking
after half an hour.

Now I just got to figure out which message getting processed is the one
causing the deadlock.... (any clues as to how to do this?)

Thanks :)




"Paul G. Tobey [eMVP]" wrote:

One or the other will win and that message will end up in the queue first,
will, presumably, be handled first by the third thread, and that application
will be released first. Then the next message will be at the top of the
queue and, again, the third thread will process that.

What's the question? If the system is about to go into suspend mode, it
will probably suspend before the about-to-suspend message gets to the UI
thread. When the device resumes, that message will still be there...

Paul T.

"skyapie" <skyapie@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BB5466B6-F02A-4F1E-9285-9B230BFD58F7@xxxxxxxxxxxxxxxx
Hi guys, me again... =)

I have a question... what happens if there are 3 threads, and 2 threads
simultaneously do a "SendMessage" to the third one?

Plus, what if Thread A is actually sending a message to the UI thread,
saying that it has received a Power Broadcast message, and that the system
was about to go into suspend mode... and the UI thread was in the middle
of
processing Thread B's message?

Thanks...

"Michael J. Salamone" wrote:

I do think it's a deadlock. Just set a break on the call to SendMessage.
When you get there, get the callstack from the UI thread. Where's it at?
If it's not calling GetMessage or some variant - i.e. not in a message
pump - that's the problem and hopefully seeing where the thread is will
clue
you in to the solution.

A little more detail on how SendMessage works across threads (high
level):
the calling thread, under the covers, posts the message to the UI thread
and
then blocks until the UI thread processes the message (by running a
message
pump e.g. GetMessage/DispatchMessage) and is completed (returns from the
WndProc). Once completed, the calling thread is unblocked. If the UI
thread is not running a message pump (as Paul pointed out, MFC provides
the
message pump), then the calling thread is blocked. Even though MFC
provides
the message pump, it's possible your UI thread is doing something (or
more
likely it's blocked) such that it didn't return to MFC so it can run its
message pump.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT
com> wrote in message news:OrNsJZBBHHA.4992@xxxxxxxxxxxxxxxxxxxxxxx
It might help to understand how a Win32 application works. Since MFC
is
just a class library, it *is* calling GetMessage(). It's just doing it
for you and you aren't coding it explicitly.

Paul T.

"skyapie" <skyapie@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CB036DCB-6925-4AA9-B844-ABB35EA0B377@xxxxxxxxxxxxxxxx
Do I need to use GetMessage?
Will ON_MESSAGE(x, y) remove the message from the message queue as
well?

"Paul G. Tobey [eMVP]" wrote:

SendMessage blocks until the window that you've sent the message to
is
done
processing it (that's why PostMessage exists). I would guess that
you
have
a deadlock there.

Thread A calls SendMessage while holding an exclusive lock on
something.
This might be a mutex, a spin lock, almost any object designed to
prevent a
second thread from accessing some resource.

Thread B calls GetMessage() and begins processing it, but, because
there's a
lock on the object, it goes into a wait state until the lock is
released.

Obviously, the lock is never going to be released, since SendMessage
doesn't
return until the message processing is complete. It's possible that
the
'lock' is something which is automatically released by the OS after
some
period of time or there might be a long time-out on the wait.

Paul T.

"skyapie" <skyapie@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9416563C-37F0-46DC-9515-949477AF299C@xxxxxxxxxxxxxxxx
Asking this question in a simpler way,

What could cause SendMessage to get stuck, causing the receipient
hWnd
to
not get it's message?

Thanks
skyapie

"skyapie" wrote:

Hi,

Has anyone ever come across the same problem and found a solution
to
the
following?

I have 1 background thread that periodically calls "SendMessage".
The
SendMessage sends a message to my main thread (which also handles
the
GUI),
saying "start processing!" The main thread then starts processing,
and
returns to the secondary thread when it has completed the
processing
it
needs
to do and updated the GUI.

This works fine most of the time, but randomly the GUI on my
application
will freeze (I can tell because there's a clock on the screen that
suddenly
just disappears... and this clock changes the time it displays by
doing a
time(¤tTime), and updating the display on every OnDraw function
call.
(Received when WM_PAINT gets processed).

The odd thing is, the application un-freeze (come back to life)
after
1/2
hour to 1 hour... And all my logging statements always stop at the
same
point
when my application freezes. I log a statement before SendMessage,
and at
the
point where the message handling function gets entered. My log
shows
that
the
SendMessage statement gets executed, but the message handling
function in
the
active view doesn't get entered.

Can anyone help please?? I have no clue how to debug into
SendMessage,
let
alone reproduce this consistently. The freezing seems to happen
randomly
at
the same point in the code. (IE: it works most of the time.... )

Much appreciated
skyapie











.

Relevant Pages

  • Re: SendMessage (in secondary thread) freezes application GUI thre
    ... A little more detail on how SendMessage works across threads: ... the UI thread is not running a message pump (as Paul pointed out, ... This might be a mutex, a spin lock, almost any object designed to ...
    (microsoft.public.windowsce.app.development)
  • Re: SendMessage (in secondary thread) freezes application GUI thre
    ... A little more detail on how SendMessage works across threads (high ... the calling thread is unblocked. ... message pump), then the calling thread is blocked. ... This might be a mutex, a spin lock, almost any object designed to ...
    (microsoft.public.windowsce.app.development)
  • Re: SendMessage (in secondary thread) freezes application GUI thre
    ... I'll try stepping into the SendMessage and check out the callstack though, ... the calling thread is unblocked. ... message pump), then the calling thread is blocked. ... This might be a mutex, a spin lock, almost any object designed to ...
    (microsoft.public.windowsce.app.development)
  • Re: SendMessage (in secondary thread) freezes application GUI thre
    ... I'll try stepping into the SendMessage and check out the callstack though, ... the calling thread is unblocked. ... message pump), then the calling thread is blocked. ... Thread A calls SendMessage while holding an exclusive lock on something. ...
    (microsoft.public.windowsce.app.development)
  • Re: SendMessage (in secondary thread) freezes application GUI thre
    ... I can see that there's a resource lock somewhere, ... Thread A calls SendMessage while holding an exclusive lock on something. ... but the message handling function ...
    (microsoft.public.windowsce.app.development)
Loading