Re: Thread execution
Doug Harrison [MVP] wrote:
On 24 May 2006 19:16:19 -0700, aditya_min1978@yahoo.com wrote:
Thanks Doug for ur reply. ya, calling sendmessage will block the caller
thread if the window was not created by the other than caller thread
While a thread is waiting for SendMessage to return, it basically sits
idle. It is, however, allowed to perform one task: if another thread in
the system sends a message to a window created by a thread that is
waiting for SendMessage to return, the system will process the sent
message immediately. The system doesn't have to wait for the thread to
call GetMessage, PeekMessage, or WaitMessage in this case.
You sound like you've been reading Raymond Chen's blog. :) I think if you
were to ask around, you'd find a lot of people who've been programming
Windows forever would not be aware that the deadlock potential is mitigated
somewhat by the behavior you described. I learned about it myself only
within the last couple of years.
Doug:
I must say I am truly shocked by this revelation, as it appears to have
the potential to undermine the great advantage of using SendMessage()
between threads: data integrity. That is, I always thought that you
could safely pass stack-based variables in SendMessage() because they
could not be changed (by the sending thread itself) until the call returned.
I use a system with a "window-less UI thread" where the main GUI thread
uses PostThreadMessage() to request tasks of the secondary thread, and
the secondary thread uses SendMessage() to return the results. Despite
widespread criticism of using SendMessage(), I believe this is a valid
scheme, and one that is not affected by this revelation.
But I am still disturbed by this news. In fact this feature seems to
have great potential for making a badly written program operate
"incorrectly", where otherwise it would exhibit a symptom of trouble by
locking up.
David Wilkinson