More on Messages and Threads
Back to Introduction to Messages
Back to Win32 ASM Page
Threads and windows
Whenever a window is created
it is "bound" to the current
thread. That thread is the only thread that can execute the
window procedure for that particular window. Consequently
the only thread that can process messages for that window. In a
the thread "owns" the window.
another window (of the same class) can be created in
allowing the two windows to process messages
concurrently. Because more than one thread can be executing a
given window procedure
the following discussions talk about
functions being "called by the thread" instead.
Preempting or nonpreempting?
While the thread system is preemptive
the message system is not.
A thread is preempted solely to let other threads run. A thread
is never preempted to change its point of execution. Thus a
won't respond immediately to new messages.
[But see same-thread sends.]
That's because message systems have three basic components:
and receivers. A sender routine will put a
message in some designated queue
and a receiver routine must
pull it out before a message handler can process it. If a
receiver routine isn't called by a thread
the thread cannot
handle any messages sitting in the queue. Windows provides two
functions for receiving messages: GetMessage and PeekMessage.
Threads and message queues
messages are delivered to threads. That means each
thread that expects messages will have its own message queue.
Because each window is associated with exactly one thread
PostMessage can determine which thread to post to (without
needing a thread argument).
"Sent" messages are
on the surface
delivered to windows.
Because threads do the work of handling received messages
messages must actually be delivered to threads. Except for
same-thread messages [see Same-thread
such messages must be placed in a thread message
queue -- one that is associated with the destination window.
Whether or not this queue is the same as the "PostMessage" queue
is unimportant. It's only important for the system to know if a
message is from a "SendMessage" function or a "PostMessage"
Thread blocking and SendMessage
When sending a message to a window
the sending function may need
to wait for a reply. While it is waiting
thread which called the function is said to be
blocked. This situation prevents the thread from
handling any messages for other windows it "owns". Thus window
contents don't get updated
and when a window is uncovered
doesn't get redrawn.
When SendMessage sends a message to a window in another
it waits for a reply which is issued when the receiving
thread calls ReplyMessage. An explicit reply is usually not
necessary because when a window procedure exits
automatically called. An explicit ReplyMessage will be necessary
to avoid deadlock if there is chain of unfinished
SendMessage calls that involves more than one thread in a
circular fashion. [See Deadlock
The SendMessage chain
thread 1) --> (B
thread 2) --> ...
thread n) --> (D
[back to] thread 1)
will deadlock when C (in thread n) sends a message to D
if none of the window procedures have called ReplyMessage. If any
of the invoked window procedures (other than D) call ReplyMessage
before calling SendMessage
the chain is broken.
a thread blocking function
is used quite often to
send a message to a window in the same thread. Under
this function would put the message on a queue and
then force the thread to wait for itself to reply. Since it's
it can't reply--deadlock. In this special case
Windows will directly call the proper window
procedure as if it were a subroutine. In effect
this is thread
preemption for the purpose of responding to new messages.
Because it doesn't require the message to be pulled out of a
this behavior allows messages to be processed without a
message loop. For example
CreateWindowEx can invoke your special
and draw the window frame before your app enters
its message loop. Also
any window (created in the same thread)
can be updated immediately by sending it the appropriate message.
But be aware that this immediate response occurs only
when a message is sent (with SendMessage) to a window in the
Forms of message transmission
SendMessage is a thread blocking function. It always waits for a
SendMessageTimeout blocks like SendMessage
but it unblocks
if the receiver takes too long to reply. You specify the timeout
SendNotifyMessage is a nonblocking function. It doesn't wait
for a reply
unless the destination window is in the same thread.
SendMessageCallback is another nonblocking function. It also
doesn't wait for a reply
unless the destination window is in the
same thread. You specify a callback routine which will be
executed when the receiving thread replies.
PostMessage is completely nonblocking. It never waits for a
reply. You must target a window. The window determines which
thread will receive the message.
PostThreadMessage is nonblocking and can't target a window.
You must target a thread.
PostQuitMessage is nonblocking and posts a WM_QUIT message to
the current thread.