January 1997

Microsoft Systems Journal Homepage

Multithreading and Inproc Servers

Each thread in a process can determine the threading model of the objects that it will export. Threads that call CoInitializeEx with the COINIT_MULTITHREADED flag are indicating to COM that all objects marshaled from that thread are thread-safe and can be manipulated freely by any other thread in that is created by the user or that COM may need to create to receive incoming method requests. This puts the responsibility for thread-safety on the object implementor but allows greater concurrency and incurs the lowest method invocation overhead. Threads that use this model are said to belong to a multithreaded apartment (MTA). This model is often referred to as the freethreaded model.
Threads that call CoInitializeEx with the COINIT_ APARTMENTTHREADED flag (or simply call CoInitial-ize) are indicating to COM that all objects that are marshaled from this thread are not thread-safe, can only be manipulated by this thread, and that the incoming method calls must be dispatched via a Windows message. This puts the responsibility for thread-safety on COM. The inherent serialization of method calls reduces the potential concurrency and the additional use of the Windows message queue incurs the somewhat greater method invocation overhead. Threads that use this model are said to belong to a single-threaded apartment (STA). This model is often referred to as the apartment model.
Each thread in a process that uses COINIT_APART-MENTTHREADED gets its own STA. All threads in a process that use COINIT_MULTITHREADED share a single MTA. While it is legal to have different threads in the same process using different threading models, it is impossible to change the model for a given thread once CoInitializeEx has been called. (This differs from the description in my May 1996 DCOM article, based on beta 1 of Windows NT 4.0, which forced all threads to use the same model.)
Out-of-process servers indicate their threading model by calling CoInitializeEx with the appropriate parameter. In contrast, in-process servers tend to be passive chunks of code that are loaded by client programs that have their own idea of which threading model to use for any particular thread. COM goes to great pains to ensure that the (lack of) thread-safety of an in-process server is respected and that in-process servers can be used irrespective of the threading model of the client. If the model of the client does not match that of the server, COM will create a new thread to deal with the DLL based on the CLSID's in-process threading model. COM then silently marshals the resultant interface pointers to the client's thread, establishing an intraprocess proxy/stub connection. This implies that if an in-process server is using custom interfaces, a proxy/stub pair is required for wrong-threaded accesses in the same address space.
Inprocess servers fall into four categories that are distinguished by a named value, "ThreadingModel," which may be present at the InprocServer32 key. Figure A lists the differences between the four types of DLLs.


© 1997 Microsoft Corporation. All rights reserved.
Terms of Use
.