Re: MFC and threads
On Sat, 07 Apr 2007 14:16:42 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
Actually, I have done it. Writing a lot of detailed code is sometimes counterproductive
in conveying an idea, which is why I usually omit error checking code...it should be
obvious how to write it most of the time, but exactly what gets written is
application-specific.
Omitting the error-checking code wasn't the issue; mentioning that you need
to error-check it at all reinforced the validity of the method, and it's
the validity of the method that I took issue with, especially given its
near equivalence to the much condemned interthread SendMessage.
PnP handling in drivers is handled by sending the IRP downward in the stack, then waiting
on a KEVENT object that is declared on the stack. The IRP completion routine does a
KeSetEvent that allows the original thread to resume. This is a useful paradigm in a
variety of contexts.
As long as the event is guaranteed to be set, it's fine. If it isn't, then
you need some escape valve to prevent blocking forever.
The performance issue is that if you have to modify a worker thread to use asynchronous
looping (by making it a UI thread), you incur a performance penalty, quite possibly an
unacceptable one. It is like the old PeekMessage technique of Win16, which could kill
your performance in a critical loop.
Besides performance, it means introducing unnecessary complexity and
unnecessarily maintaining state across time and space, hence what I said in
my other message yesterday, "On the other hand, if you try to turn
an inherently sequential process into an event-driven state machine, you'll
just introduce complexity reminiscent of Win16 PeekMessage (AKA
cooperative) multitasking." IMO, performance concerns are secondary,
because I wouldn't consider an async approach unless the problem actually
called for it. So for me, it isn't first a question of "Will it be fast?"
but rather, "Does the solution fit the problem?"
It isn't a simple design space. For example, blocking PostMessage has a quite different
effect on a UI thread.
The nicest thing about PostMessage is that the message is delivered to a
message queue. I've not seen this given as a reason to avoid it (at least
not like what I'm about to say), but interthread SendMessage is less
predictable. Threads blocked in it will process incoming messages sent from
other threads, but you can mitigate this by using interthread SendMessage
only from worker threads, which by definition don't receive messages.
However, while an UI thread can pass PM_QS_SENDMESSAGE to PeekMessage and
prevent dispatching pending interthread sent messages, nothing can prevent
this for GetMessage and WaitMessage. I don't think this is necessarily a
problem for GetMessage, unless you're expecting the message to only ever be
posted, such that you can examine it right there in the message loop when
it comes in. So, this really leaves just the relatively obscure WaitMessage
to worry about as a dispatch point. This is all I know that distinguishes
interthread SendMessage from PostMessage/WFSO(INFINITE). Did I cover your
"quite different effect", or were you thinking about something else?
--
Doug Harrison
Visual C++ MVP