Synchronizing SINGLE-threaded Windows apps?

  • Thread starter Thread starter Christoph Nahr
  • Start date Start date
C

Christoph Nahr

Multi-threaded applications are well-supported by the .NET Framework.
Surprisingly, it's much harder to handle single-threaded applications!

I'm talking about the really nasty Windows habit of checking the
message queue of the GUI thread at the most inopportune moments, i.e.
whenever some seemingly innocuous method that relies on Win32 calls is
executing. If the user happens to press a hotkey or click on some
window icon (like "X") at this point, Windows makes a forced
subroutine call to the handler for that event. Meanwhile, the
previously executing application method is put on ice, as if it had
called that new handler as a subroutine.

I understand that this quasi-multitasking is the heritage of 16-bit
Windows where there were no multiple threads. Well, it's really
annoying today because it can cause synchronization problem when one
message handler puts the application in a certain state that renders
it unable to respond to certain other message handlers... and then,
sure enough, those other handlers get triggered by user action while
the first handler is still executing!

That's really nasty because the usual thread synchronization methods
don't work -- everything's executing on the same thread, so attempts
to check a lock either fall through or block eternally.

So far the only "solution" (more of a hack really) I've found is to
simply return from the most recent message handler when I've found the
application state inadequate, and perhaps manually save callback
instructions for the handler that was already executing.

Is there some kind of elegant solution for this problem? Any MSDN
articles discussing this issue?
 
Hi Christoph,
whenever some seemingly innocuous method that relies on Win32 calls is
executing. If the user happens to press a hotkey or click on some
window icon (like "X") at this point, Windows makes a forced
subroutine call to the handler for that event. Meanwhile, the
previously executing application method is put on ice, as if it had
called that new handler as a subroutine.
Do you mean the system will check the message queue and process some
message when executing each win32 call? IMO, In win32, windows message loop
does not work in this way. For more information on win32 message loop and
message queue, you may read this docuementation in MSDN:
<About Messages and Message Queues>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI
/WindowsUserInterface/Windowing/MessagesandMessageQueues/AboutMessagesandMes
sageQueues.asp

Also, the problem seems like there are some calls to Application.DoEvents ?
Application.DoEvents will create a local message loop and process several
messages in the message loop and return, it is used to keep the UI
responsive, of course it is also likely to cause the wnd_proc re-entrance
problem.

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Back
Top