COINIT
A set of
values from the COINIT enumeration is passed as the dwCoInit parameter
to CoInitializeEx. This value determines the concurrency model used for
incoming calls to objects created by this thread. This concurrency model can be
either apartment-threaded or multi-threaded.
The COINIT
enumeration is defined as follows:
typedef enum tagCOINIT{
COINIT_APARTMENTTHREADED
= 0x2, // Apartment model
COINIT_MULTITHREADED =
0x0, // OLE calls objects on any thread.
COINIT_DISABLE_OLE1DDE = 0x4,
// Don't use DDE for Ole1 support.
COINIT_SPEED_OVER_MEMORY = 0x8,
// Trade memory for speed.
} COINIT;
Members
COINIT_MULTITHREADED
Initializes
the thread for multi-threaded object concurrency (see Remarks).
COINIT_APARTMENTTHREADED
Initializes
the thread for apartment-threaded object concurrency (see Remarks).
COINIT_DISABLE_OLE1DDE
Disables DDE
for Ole1 support.
COINIT_SPEED_OVER_MEMORY
Trades memory
for speed.
Remarks
When a thread
is initialized through a call to CoInitializeEx, you choose whether to
initialize it as apartment-threaded or multi-threaded by designating one of the
members of COINIT as its second parameter. This designates how incoming calls
to any object created by that thread are handled, that is, the object s
concurrency.
Apartment-threading,
the default model for earlier versions of Windows NT, while allowing for
multiple threads of execution, serializes all incoming calls by requiring that
calls to methods of objects created by this thread always run on the same
thread - the apartment/thread that
created them. In addition, calls can arrive only at message-queue boundaries
(i.e., only during a PeekMessage, SendMessage, DispatchMessage,
etc.). Because of this serialization, it is not typically necessary to write
concurrency control into the code for the object, other than to avoid calls to PeekMessage
and SendMessage during processing that must not be interrupted by other
method invocations or calls to other objects in the same apartment/thread.
Multi-threading
(also called free-threading) allows calls to methods of objects created by this
thread to be run on any thread. There is no serialization of calls - many calls may occur to the same method or to the
same object or simultaneously. Multi-threaded object concurrency offers the
highest performance and takes the best advantage of multi-processor hardware
for cross-thread, cross-process, and cross-machine calling, since calls to
objects are not serialized in any way. This means, however, that the code for
objects must enforce its own concurrency model, typically through the use of
Win32 synchronization primitives, such as critical sections, semaphores,
or mutexes. In addition, because the object doesn t control the lifetime
of the threads that are accessing it, no thread-specific state may be stored in
the object (in Thread-Local-Storage).
See Also