deadlock when using waitOne in a STA thread
Hi,
I have the problem described bellow with the calls to WaitHandle.WaitOne
causing re-entrancy on main GUI thread (STA) of a .NET application and I
would like to find out:
- did anybody else run into the same problem?
- is it a known issue? is there a fix for it?
- is there a workaround for it?
- if no fix/workaround I would like to find out the complete list of
messages that are being handled (dispatched by ole32.dll OLE/COM message
pump) when doing WaitOne on a STA thread.
The problem is:
I have 2 (or more) calls pending to execute on the main gui thread (I am
actually doing Invoke on some control)
the first call, at some point does WaitHandle.WaitOne.
at this point, if a Windows message comes to the app (like
WM_POPUPSYSTEMMENU - 0x0313 ) triggered by a right-click on the task bar
icon of the app the following happens:
- the app processes this message
- the app starts processing other pending messages - like my second
invoke
- at this point my app is deadlocked, because it is not supposed to
enter the second call before finishing processing the first one.
- also at this point the entire system is not behaving properly - for
example I cannot bring up any window by clicking on the taskbar icon
important note: if I would not do right click on the taskbar icon of my app,
and just let it work in background, everything would be ok.
After investigating this issue for a while, I found that WaitOne is not
actually a blocking call when called from an STA thread.
The only reference I found related to this matter in MSDN pages is here:
http://msdn.microsoft.com/en-us/library/74169f59.aspx .
Quoting from that page:
"WaitHandle..::.WaitOne,WaitHandle..::.WaitAny, WaitHandle..::.WaitAll,
Monitor..::.Enter, Monitor..::.TryEnter, Thread..::.Join,
GC..::.WaitForPendingFinalizers, and so on are all responsive to
Thread..::.Interrupt and to Thread..::.Abort. Also, if your thread is in a
single-threaded apartment, all these managed blocking operations will
correctly pump messages in your apartment while your thread is blocked."
If the apartment state is STA this function actually creates a message loop
that is processing some events (for now I have been able to identify 2 of
them (WM_POPUPSYSTEMMENU and WM_ACTIVATEAPP). The problem is that these
messages triggers processing of other messages in the queue (like the
registered messages used for invoke in .NET ).
I have attached a simplified application to demonstrate the issue. In this
app I have created a thread from where I am calling multiple times the same
function which is suppose to execute on the GUI thread.
I have put some console prints to show that it is executing another invoke
on the main thread even if it is supposed to stay in the wait.
Another thing, in my app the calls to some functions are not supposed to
re-enter (and we are protecting them with the waitOnes) but if I modified
the sample app (attached to this mail) to have a non-blocking re-entrancy ,
I noticed if I right click on the taskbar icon while the first call is in
waitOne, all the other calls will be executed before the first call ends -
this is actually easy to explain since the other calls are not processed by
the app message loop but they are processed by the message loop created by
the WaitOne. however I don't think this should be the normal behavior - that
is: when I invoke 3 calls on some thread, the order of execution should be
the order of the invokes.
waiting forward for your replies
Daniel.
date: Thu, 5 Jun 2008 16:15:47 +0300
author: Daniel Cuculescu
