5

I have this simple code:

public void Run()
{
   var invokerThread = new Thread(new ThreadStart(RunOnBackground));
   invokerThread.Start();
}

private void RunOnBackground()
{
   Trace.WriteLine("hi");
   ...
}

Unfortunately when running this code (from third party process) the thread doesn't really run. Either in process explorer and in VS debugger I see that the thread is created and its state is "Running".

The main thread's apartment is STA and I've tried both STA and MTA on internal thread.

When I add to the Run() method at the end invokerThread.Join(); then the thread does run. But then again it doesn't really help.

What am I missing?

Edit: Here is some more information regarding the code hosting -

Run() method is called via COM interop from a process which is also managed executable assembly (the reason COM interop is used is because all other components in the system are native).

The method RunOnBackground() includes some more code after the tracing and generally its execution lasts between 10 - 20 seconds, including starting another process and waiting for its termination. Also I have some other areas in the code where I write some debug information to the Trace. While debugging the code, Run() runs as usual and after invokerThread.Start(); invokerThread's state is "Running" (though breakpoints inside the RunOnBackground() method don't stop).

When I add invokerThread.Join() at the end of the Run() method the debugger goes to RunOnBackground() after the Join().

Aaron
  • 2,236
  • 1
  • 16
  • 28
  • You should not show a MessageBox inside worker thread. Change to use Trace – Harvey Kwok Dec 12 '10 at 17:23
  • Updated the code. Still doesn't work.Please see the response I've wrote to Martin. – Aaron Dec 12 '10 at 17:33
  • You said: "Unfortunately when running this code (from third party process) the thread doesn't really run." How exactly are you "running this code"? – Eric Dahlvang Dec 12 '10 at 17:42
  • I think it is related to how you host your code. Can you please provide more information on the hosting process? Also, you said the thread doesn't really run but in the process explorer, the thread's state is in the "Running" state. Did you mean that you saw the thread is running but you didn't see the trace coming out? Did you set a breakpoint to verify the thread is really running? – Harvey Kwok Dec 12 '10 at 17:45
  • Edited the question: added some more description. – Aaron Dec 12 '10 at 19:35

2 Answers2

3

There's some crucial information missing about what RunOnBackground() really does. This is otherwise a good match for what happens when you use apartment threaded COM objects on a worker thread. COM automatically marshals any method call on such an object from the worker thread to the STA thread on which it was created.

That can only work well when the STA thread observes STA threading requirements. It must pump a message loop and cannot block. Breaking those rules makes deadlock very likely, the worker thread call cannot complete until the STA thread dispatches the marshaled call. A sure sign that this is what is going on is seeing Thread.Join() solve the problem. It pumps a message loop internally in the CLR when it is called on an STA thread.

To diagnose this, you'll need Debug + Windows + Threads to see what that worker thread is blocking on. If my guess is right, it will be buried deep inside of the COM plumbing code, waiting for the marshaled call to complete. You can only see this by enabling unmanaged code debugging and setting up the Microsoft Symbol Server so you get debugging symbols for the plumbing code and get a reliable stack trace.

Fixing this is going to be difficult. You cannot magically flip a switch and make code run on a thread when it has explicitly stated that it doesn't support multi-threading. It is imperative that you create the instance of the COM object on the same thread that calls its methods. And that thread has to be an STA thread. Check this sample code for the approach. If you don't control the creation of the COM object then you're stuck.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Hans, thanks for the brief answer. You wrote that "... see what that worker thread blocking on.". Actually while debugging I see that after Start() the worker thread state is changed to "running". The RunOnBackground() method calls other methods that one of them start another process and waits to its exit, but I've also tried to simplify the scenario by commenting out everything inside RunOnBackground() method and writing some simple Trace.Write() and some assignments (like var x = 1;). – Aaron Dec 14 '10 at 07:57
0

I may say something stupid, but here is what I saw in MSDN Threads.

Look at the examples section at the end.

The output of the example is interesting, you can see there that the Thread created and started only starts executing when the main thread does a Sleep(0) or a Thread.Join().

It seems to be what exactly happens to you, doesn't it ?

Maybe try with a Sleep(0) on your main thread to really launch your working Thread.

Another workaround would be to use the BackGroundWorker.

As its name says it, it works on the Background and is really easy to use. It may be of much use to you.

LaGrandMere
  • 10,265
  • 1
  • 33
  • 41