COM multi-thread principle and application

COM multi-threaded principle and application directory: COM multi-thread principle and application ... 1

Directory: ... 1

Preface: ... 1

Suites: ... 1

Set of definitions: ... 1

Satellite classification: ... 2

Entering and exit in the suit:. 2

Synchronization of the object: ... 2

Component object synchronization: ... 2

COM object thread model: .. 2

Types of object thread models in the process:. 2

ATL support for multi-threaded: .. 3

Object reference protection: ... 3

Protection of member variables: ... 4

Preface: COM multithreading has always been a problem that is not easy to figure out, and I have been plagued for a long time, especially the terminology in the thread, always uniform. This article is to make a summary I have learned, this article does not guarantee certain correct, but will gradually improve the correction over time.

Space: The definition of the suite: I personally think that << COM technology insider >> The definition of the suite is wrong, should be defined in << COM nature >>. << COM Technology Inside >> ----- Suitment, a conceptual entity consisting of user interface thread (socket thread) and a message loop. << COM Nature >> ------ Space Defines a logical combination of a set of objects, which share the same set of concurrency and re-entry. A thread wants to use COM, you must first enter a suit. COM stipulates that only threads running in the object suite can access the object. Classification of Suites: COM Defines Two types of sockets, STA (single-threaded suites) and MTA (multi-threaded suites). STA features that there is only one thread run in the suite, and it must be an initial thread that creates this suite. Therefore, the development of components running only in STA does not need to consider thread synchronization. The STA contains an invisible window, so the process of processing the message queue through the window of the message loop mechanism, ensuring that only one call request is executed at the same time, which is why the component does not need to handle synchronization.

The MTA features that there can be multiple threads in the suite, and you can also create new threads. Components running in MTA must implement the synchronization of threads.

Entering and exiting in a suite: Threads enter the suite through the CoinitializeEx function, the second parameter of the function is marked with the set of room by passing the Coinit_APARTMENTTHREADED and COINIT_MULTITHREADED. If you pass the Coinit_ApartmentthReaded, the thread will create your own private suit, others can't enter. If Coinit_MultithReaded is passed, the thread will enter the MTA within the current process range. The thread calls the Couninitialize function is used to exit the outlines. Only after exiting before entering other types of sockets.

Synchronization of objects: Synchronization of component objects: Component objects can be divided into single-threaded objects and multi-threaded objects based on whether you support multithreading synchronization. COM object thread model: Each COM object can determine what you will run in. This is called the thread model of the COM object. The component will run in a suit, which is determined by the component developer, and the client that calls the component does not need to be concerned. However, if the set of intercom in the package and component running in the call is not the same set, COM will insert the proxy / settlement mechanism, call the thread to call the approach to the agent in its own suite, and the object will run in the suite it needs. . Types of object thread models within the process: The type of thread model depends on the value of threadingmodel in the registry ---------- 1) Both representation that the component can run in STA and MTA 2) Free Indicates that the component can only run In MTA 3) Apartment indicates that the component can only run in STA 4), which can only run in the first STA (main STA) created in the process. If you call the thread's suite to meet the requirements of the thread model of the process within the process, create a component object directly and do not require a proxy. If you call the thread's set of threads that cannot meet the requirements of the thread model of the components within the process, COM will create an object in another suitable suite (if there is no suitable suite, COM will create one) to create an object, and then return the callback thread. If the components and clients are not in the same process or not in the same machine, it is inevitably in two suite, COM will create a proxy / stub. If the thread model of the component object is Both or Free, the component must be a multi-threaded object. If the thread model of the component object is empty, the component can be a single-threaded object or a multi-threaded object. At this time, the synchronization mechanism inside the multi-threaded object is actually meaningless, because there is no multiple threads to access the object. If the thread model of the component object is Apartment, the situation will be divided into two: a) There is no global variable and static variable inside the component, and the component can be a single-threaded object B) There is a global variable and static variable inside the component. Components should be multi-threaded objects. And access to global variables and static variables. ATL support for multi-threaded support: The support of synchronization in the COM object in ATL has its own consideration: If the COM object itself does not consider a single-threaded object that is synchronized, ATL should not include any data member of the object, including object reference variables m_cref Synchronize protection. Because synchronous protection is an additional resource. The principle in the ATL is to synchronize only when it should be protected. This is the design purpose of ATL - all for efficiency. Object references: CCOMSINGLETHREADMODEL, CCOMMULTITHREADMODEL, CCOMMULTITHREADMODELNOCS class define static member functions increment and Decrement. The template parameters for the CComobjectRootex class accept the above three classes and use their static member functions, while our component implements the class from the CComobjectroTex class, which has obtained the function of synchronizing object references based on whether our components support multithreading. In one sentence, we can get a CComobjectroTroTex class with a suitable template parameter. Such as our class:

Class ATL_NO_VTABLE CMIS:

Public CComObjectRootex , CMIS classes do not need to consider synchronous protection of object references because our component objects are single-threaded objects, and thread model is empty or Apartment. But please note that the default thread model in the component class script of the ATL project is Both, which will bring problems, so we manually modify it. If we change the code as follows: Class ATL_NO_VTABLEX , then our component object reference count is synchronously protected, and our component objects are responsible for synchronous protection. This makes it possible to synchronize the member variables if there is a member variable in the CMIS class.

Protection of member variables:

Synchronous protection using critical regions. We must use class CCommultithreadModel. Our components implements the class derived from CComObjectRootex class. The method of use is extremely simple. We only need to add the following code as needed to prevent multiple threads from simultaneously executing: ObjectLock Lock (this);

If you want to use multiple critical regions, it is not so simple, but unless you must, I don't recommend this because it is easy to cause dead locks. If you must use, you must first read << Windows Core Programming >> and << Win32 Multithreaded Program Design >> These two books.