An MTA Console application calling an STA COM object from multiple threads

Question

Although there are many questions about COM and STA/MTA (e.g. here), most of them talk about applications which have a UI. I, however, have the following setup:

• A console application, which is by default Multi-Threaded Apartment (Main() explicitly has the [MTAThread] attribute).
• The main thread spawns some worker threads.
• The main thread instantiates a single-threaded COM object.
• The main thread calls Console.ReadLine() until the user hits 'q', after which the application terminates.

A few questions:

• Numerous places mentions the need of a message pump for COM objects. Do I need to manually create a message-pump for the main thread, or will the CLR create it for me on a new STA thread, as this question suggests?
• Just to make sure - assuming the CLR automagically creates the necessary plumbing, can I then use the COM object from any worker thread without the need of explicit synchronization?
• Which of the following is better in terms of performance:
  • Let the CLR take care of the marshaling to and from the COM object.
  • Explicitly instantiate the object on a separate STA thread, and have other thread communicate with it via e.g. a ConcurrentQueue.

Cirsoid

Related: How to handle COM events from a console application? – Oersted

Answer 1

Yes, it is possible to create a STA COM object from an MTA thread.

In this case, COM (not CLR) will create an implicit STA apartment (a separate COM-owned thread) or re-use the existing one, created ealier. The COM object will be instantiated there, then a thread-safe proxy object (COM marshalling wrapper) will be created for it and returned to the MTA thread. All calls to the object made on the MTA thread will be marshalled by COM to that implicit STA apartment.

This scenario is usually undesirable. It has a lot of shortcomings and may simply not work as expected, if COM is unable to marshal some interfaces of the object. Check this question for more details. Besides, the message pump loop, run by the implicit STA apartment, pumps only a limited number of COM-specific messages. That may also affect the functionality of the COM.

You may try it and it may work well for you. Or, you may run into some unpleasant issues like deadlocks, quite difficult to diagnose.

Here is a closely related question I just recently answered:

StaTaskScheduler and STA thread message pumping

I'd personally prefer to manually control the logic of the inter-thread calls and thread affinity, with something like ThreadAffinityTaskScheduler proposed in my answer.

You may also want to read this: INFO: Descriptions and Workings of OLE Threading Models, highly recommended.

Berkin

Answer 2

This is done automagically by COM. Since your COM object is single-threaded, COM requires a suitable home for the object to ensures it is used in a thread-safe way. Since your main thread is not friendly enough to provide such guarantees, COM automatically creates another thread and creates the object on that thread. This thread also automatically pumps, nothing you have to do to help. You can see it being created in the debugger. Enable unmanaged debugging and look in the Debug + Windows + Threads window. You'll see the thread getting added when you step over the new call.

Nice and easy, but it does have a few consequences. First off, the COM component needs to provide a proxy/stub implementation. Helper code that knows how to serialize the arguments of a method call so the real method call can be made on another thread. That's usually provided, but not always. You'll get a hard to diagnose E_NOINTERFACE exception if it is missing. Sometimes TYPE_E_LIBNOTREGISTERED, a common install problem.

And most significantly, every call on the COM component will be marshaled. That's slow, a marshaled call is usually around 10,000x slower than a direct call on a method that itself takes very little time. Like a property getter call. That can really bog your program down of course.

An STA thread avoids this and is therefore the recommended way to use a single-threaded component. And yes, it is a requirement for an STA thread to pump a message loop. Application.Run() in a .NET program. It is the message loop that marshals calls from one thread to another in COM. Do note that it doesn't necessarily mean that you must have a message loop. If no call ever needs to marshaled, or in other words, if you make all the calls on the component from the same thread, then the message loop isn't needed. That's typically easy to guarantee, particularly in a console mode app. Not if you create threads yourself of course.

One more nasty detail: a single-threaded COM component sometimes assumes it is created on a thread that pumps. And will use PostMessage() itself, typically when it uses worker threads internally and needs to raise events on the STA thread. That will of course not work correctly anymore when you don't pump. You normally diagnose this by noticing that events are not being raised. The common example of such a component is WebBrowser. Which heavily uses threads internally but raises events on the thread on which it was created. You'll never get the DocumentCompleted event if you don't pump.

So putting [STAThread] on your Main() method might be enough to get happy fast code, even without a call to Application.Run(). Just keep the consequences in mind, seeing a method call deadlock or an event not getting raised is the tell-tale sign that pumping is required.

Nighttime

A great answer, thanks. You mentioned that if I make all the calls from the main thread, a pump may not be needed. What is so special about the main thread? How is it different from creating the object on another STA thread, and making all the calls from that thread? – Cirsoid

Nothing. The only thing that matters is whether the method calls are made by the thread that created the object. That is always thread-safe. It does matter to exactly how you make it STA. The main thread is special, Windows creates it when it starts the process. So requires the [STAThread] attribute. Any thread you start requires Thread.SetApartmentState(). – Nighttime

I'm still confused. if I have an asmx service that uses a dll - in this dll I am creating a single apartment thread which does MQ pumping and does it thing. That means each concurrent webservice request should be creating it's own instance with it's own STA thread - the COM object should behave. And it does for the most part - but under high load the COM object code locks up and we time out on the WS call every time. Reboot is required to restore the functionality - this makes me think there can only ever be one instance of the WebBrowser. After a single failure, Subsequent requests pile up. – Plerre

Interestingly enough this describes my problem almost exactly - but we're already implementing this solution in the code and encountering the same behavior: blogs.msdn.microsoft.com/asiatech/2012/02/20/… – Plerre

Answer 3

Do I need to manually create a message-pump for the main thread,

No. It is in the MTA therefore no message pump is needed.

or will the CLR create it for me on a new STA thread

If COM creates the thread (because there is no STA in the process) then it also creates the message pump (and a hidden window: can be seen with the SPY++ and similar debugging tools).

COM object from any worker thread without the need of explicit synchronization

Depends.

If the reference to the single threaded object (STO) was created in the MTA then COM will supply the appropriate proxy. This proxy is good for all threads in the MTA.

In any other case the reference will need to be marshalled to ensure it has the correct proxy.

is better in terms of performance

The only answer to this is to test both and compare.

(Remember if you create the thread for the STA and then instantiate the object locally you need to do the message pumping. It is not clear to me that there is any CLR level lightweight message pump—including WinForms just for this certainly isn't.)

NB. The only in depth explanatory coverage of COM and the CLR is .NET and COM: The Complete Interoperability Guide by Adam Nathan (Sams, January 2002). But it is based on .NET 1.1 and now out of print (but there is a Kindle edition and is available via Safari Books Online). Even this book doesn't describe directly what you are trying to do. I would suggest some prototyping.

Kwashiorkor