| Date: | June 2, 2004 / year-entry #217 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20040602-00/?p=39053 |
| Comments: | 7 |
| Summary: | In the absence of an explicit threading model for your COM object, you get the "main" threading model. The "main" threading model is little-known, and that's a good thing. It's a relic from the days before multi-threading. The first thread in a process to initialize COM becomes declared the "main" thread. (It might be the... |
In the absence of an explicit threading model for your COM object, you get the "main" threading model. The "main" threading model is little-known, and that's a good thing. It's a relic from the days before multi-threading. The first thread in a process to initialize COM becomes declared the "main" thread. (It might be the first thread to initialize COM in apartment model; I forget.) When a "main" threaded object is created, COM marshals the creation call to the main thread, creates the object, then marshals the result back to the creator's thread. Similarly, when you invoke any method on the object, the call is marshalled to the main thread, invoked, then the result is marshalled back. In other words, a "main" threaded object is like an apartment threaded object, with the additional constraint that the only apartment that can use it is the one that the "main" thread belongs to. As you can imagine, this is a horrific performance penalty in any multithreaded application, since there is so much marshalling going on. Even worse, it completely bottlenecks the main thread because there are now all these objects that must be serviced on that thread and no other thread. Even worse than worse, all this marshalling creates new opportunities for re-entrancy. While waiting for the main thread to do its thing, the calling thread will likely process messages, which means that you can receive a window message at a time when you didn't expect it. So why does this awful threading model exist at all? For backwards compatibility with COM objects written before multithreaded support was added to COM. Back in those days, there was only one thread, so COM objects could be extremely lazy with their synchronization. In fact, they didn't need any! If you have only one thread, then you certainly don't need to coordinate your actions with other threads because there are none. That's also why "main" threading model is the default. Threading models were invented when multithreading support was added to COM. Before then, there were no threads, so no threading models. All old objects therefore didn't specify a threading model in their registration. The only reason you should even be aware of this ancient threading model in the first place is that if you forget to specify a threading model in your object registration, you will get the dreaded "main" threading model by default. And then you will wonder why your application's performance is horrible, and why you have all these strange re-entrancy problems. |
Comments (7)
Comments are closed. |
Does affect a COM client that registers a callback with a COM server if the COM client uses CoInitialize rather than CoInitializeEx?
CoInitialize() creates a single-threaded apartment, as noted in the very first sentence of the documentation.
In other words, CoInitialize(NULL) is 100% equivalent to CoInitializeEx(COINIT_APARTMENTTHREADED, NULL).
Yes, I know. It’s the leading sentences in your second paragraph that confuse me.
That paragraph describes how the "main" thread is determined and how the "main" thread is involved when somebody does a CoCreateInstance on an object that is marked as "main"-threaded.
Since "main"-threaded is the same as "apartment-threaded on the main thread", it doesn’t matter whether the callback you hand back (on an STA thread) is main-threaded or apartment-threaded since the behavior is the same: Always call back on the thread it was created from.
(I work on the COMCOM+ team at Microsoft)
Two small additions…Raymond is correct that the "main" STA thread is the first STA thread to be initialized in the process. And that all COM objects without an explicitly declared threading model are run on this thread. This was important, if memory serves, not just for COM objects lacking synchronization but also for certain older object runtimes that put lots of state in TLS and always expected that state to be there. So those objects *had* to be run on a dedicated thread, for the life of the process.
Second, COM was originally written to expect that the "main" STA thread, once initialized, would never, ever, go away in the process. If it did, and you tried to create another "main"-threaded COM object, you’d get an error. We relaxed this in Windows XP and later, if the "main" thread goes away, COM will now allow a new "main" thread to be designated. This was done to allow folks to use antique COM objects without having to keep a wasteful dedicated thread around. Of course this will likely break those older object runtimes I mentioned (probably in hard-to-debug ways) but it may be okay for some objects in some situations.
While I’m on the subject of COM and extension compatibility, another issue that affected a small number
Multi-threaded apartments do not pump messages.