Both COM and its predecessor, OLE, were developed at a time when Microsoft Windows did not support multithreading, so COM initially provided no support for multithreaded components. Later, as threading became ubiquitous in Windows, COM was extended to include threading support. Today, COM+ provides support and interoperability for components that use threads to varying degrees, from old-fashioned single-threaded objects to objects that can be called on any thread.
COM+ supports two primary threading models: one for user-driven graphical user interface (GUI) applications and another for worker components that do not display a user interface, both of which use the threading infrastructure provided by the operating system. The threading model designed for GUI applications is synchronized with the message queues used by Windows, making it much easier for user-driven applications to work with COM+ robustly. The threading model designed for worker components, on the other hand, does not use window messages to deliver COM+ method calls—this model works well for components that need the best possible performance and that don't have to worry about synchronizing COM+ calls with a user interface.
Both models are and will continue to be important. Unfortunately, the details of these threading models and the implications of the ways in which they can be combined can be overwhelming at first. Luckily, in most cases a deep understanding of these threading models is not crucial to the success of a project, and reading this chapter once to obtain an overview of the issues involved will be sufficient. If you design a system that makes heavy use of threads, however, you might want to work through this chapter carefully to ensure that you fully understand the implications of your design decisions.