This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(278.4, 36%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBV%3C/text%3E%3C/svg%3E)
The Situation
Suppose you have a simple native C++ application which calls CoInitializeEx(0, COINIT_MULTITHREADED). It then uses std::async to create a number of threads that run at the same time. Each thread routine also calls CoInitializeEx(0, COINIT_MULTITHREADED) and then calls CoCreateInstance to create an instance of an out of process (EXE) COM component.
The problem is that the calls to CoCreateInstance seem to be serialized. If you run ten threads, it takes say ten seconds. If you run five, it takes five seconds. The threads are definitely running at the same time.
If the thread function calls PeekMessage to ensure it has its own message queue, it makes no differences.
What do I know?
Determining the threading model for out of process COM servers is tricky because there are proxy objects, RPC threads, threading models, coclass settings, you name it.
It looks like for an inprocess COM server (a DLL) the threading model can be specific in the registry. But for an out of process EXE COM server, this is apparently handled by the coclass and not in the registry. CoCreate loads the EXE, and then the coclass registers itself by calling CoRegisterClassObject which passes in REGCLS_SINGLEUSE or REGCLS_MULTIPLEUSE depending on whether NewInstance (single use) is used or not. And that typically determines what subsequent CoCreateInstance calls will do, whether they return that same instance or a new one.
So that suggests that creating multiple instances of same out of process COM component must be serialized by Windows. Because a subsequent create instance call has to see what a previous one did when it called CoRegisterClassObject.
Is that true?
Is there any way to get those threads to create those instance all in parallel at the same time and not have the calls serialized?
This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(201.6, 57.00000000000001%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMY%3C/text%3E%3C/svg%3E)
Can you provide a sample that reproduce your problem? Have you mixed REGCLS and CLSCTX such as REGCLS_MULTIPLEUSE |CLSCTX_LOCAL_SERVER?
For your reference:
An in-process server does not call CoInitialize, CoInitializeEx, or OleInitialize to mark its threading model. For thread-aware DLL-based or in-process objects, you need to set the threading model in the registry. The default model when you do not specify a threading model is single-thread-per-process. To specify a model, you add the ThreadingModel value to the InprocServer32 key in the registry.
Thank you, your comment is correct, but this is specific to out of process, for which you do not set the threading model in the registry, it is apparently determined by the coclass, according to my googling.
it is apparently determined by the coclass, according to my googling.
For an out-of-process COM Server the threading model of a COM class is determined by the apartment of the thread that calls CoRegisterClassObject to register the class.
Sadly, even calling CoInitializeEx(0, COINIT_MULTITHREADED) on each thread and the main thread, still cause the CoCreate calls to be serialized. No matter what I tried, I got not get the calls to go through in parallel, unless CoCreate retrieves the existing instance other than a new instance.
So that suggests that creating multiple instances of same out of process COM component must be serialized by Windows. Because a subsequent create instance call has to see what a previous one did when it called CoRegisterClassObject.
Presumably you are talking about REGCLS_SINGLEUSE. If that is the case then your understanding is incorrect. The documentation for REGCLS_SINGLEUSE states "After an application is connected to a class object with CoGetClassObject, the class object is removed from public view so that no other applications can connect to it. " Consequently, each call to CoCreateInstance is independent, and so is each related server instance.
There is nothing in the COM documentation that states that calls to CoCreateInstance from multiple threads are serialized. The only related thing that comes to mind would be that a single-threaded out-of-process server would serialize incoming calls through its one message pump. This would not necessarily be the case for apartment-threaded or multiple-threaded servers.
Since the phenomenon you describe is not mentioned in the document, can you provide steps and a minimal example code to reproduce your problem?
@Ben van der Merwe Its been a while since you last responded to this thread. Can you share an example that supports the assertion that COM serializes calls to CoCreateInstance?
Or is this a dead issue?