COM Threads and Processes (Windows Embedded CE 6.0)
1/6/2010
COM provides support for various threading and process models.
Multiple threads should not access ActiveX controls, which have thread affinity because of their use of thread-specific resources.
Because the COM implementation does not support apartment threading, you cannot implement data synchronization with an apartment-threaded singleton. Instead, you must make explicit calls to thread-synchronization primitives to help protect member and global data.
This restriction does not apply to the DCOM implementation.
If the ThreadingModel** registry key is not set, the threading model defaults to "Free." In the Minimal COM implementation, Windows Embedded CE does not support concurrency management, which means that your application is responsible for synchronizing access to various objects.
However, because DCOM on Windows Embedded CE supports all threading models and interactions between apartments in the same way that Windows NT does, your application must set this registry key.
In particular, for proxy objects, you must set the ThreadingModel value to "Both," which means that both single-threaded and multithreaded apartment types are supported. If you fail to do this and a thread that belongs to a different apartment accesses the proxy object, the DCOM run-time attempts to marshal the object and fails.
In Windows NT, if the ThreadingModel registry key is not set, the threading model defaults to "Single." In Windows Embedded CE, you must specify the Single threading model explicitly.
The following table summarizes the registry settings for Windows Embedded CE and Windows NT.
| Windows Embedded CE registry key | Windows NT registry key | Threading model |
|---|---|---|
Single |
default (not set) |
Main single-threaded apartment |
Apartment |
Apartment |
Single-threaded apartment |
default (not set) |
Free |
Free threading |
Both |
Both |
Supports both single-threaded and multithreaded apartment models |
.gif "Ee488505.collapse(en-US,WinEmbedded.60).gif")
Thread/Process Affinity and Protected Server Libraries
The DCOM implementation requires every object to have thread/process affinity.
This means that threads that are within protected server libraries (PSLs) cannot create or access objects or APIs that are within a DCOM application and that also require an explicit concurrency model (that is, objects that must be initialized with a call to the CoInitializeEx function).
Specifically, this restriction applies to every callback that the OS makes to an application, and DLL initialization or termination functions, and any call to a device driver.**