"reprint" com Multithreading principle and application

The principle and application of COM multithreading

Directory:

The principle and application of COM multithreading

Directory:

Objective:

Suite:

Definition of Suite:

Categories of suites:

Entrance and exit of the Suite:

Synchronization of Objects:

Synchronization of Component Objects:

COM object Threading Model:

Types of In-process object threading Models:

ATL support for Multithreading:

Protection of Object References:

Protection of member Variables:

Changes caused by COM +:

Overview of the Context:

Context Object:

Call Object:

Objective:

COM multi-threading has been a difficult problem to understand, I have been plagued for a long time, especially in terms of COM thread terminology is always not uniform. This article is to use what I have learned to do a summary, this article does not guarantee that must be correct, but will gradually improve with the passage of time to Correct.

Suite: definition of Suite:

personally, I think that the definition of suite in <<com Technology insider >> is wrong and should be defined in >> by <<com Essence.

<<com Technology Insider >>-----

Suite (Apartment), A conceptual entity composed of user interface threads (suite threads) and a message loop.

On the essence of <<com >>------

Suite defines the logical combination of a set of objects that share the same set of concurrency and re-entry restrictions. If a thread wants to use com, it must first enter a Suite. COM stipulates that only threads running in the object suite can access the Object.

Categories of suites:

COM defines two types of suites, STA (single-threaded suite), and MTA (multi-threaded suite).

The STA features a single thread that is always running in the suite and must be the initial thread to create the Suite. Thus developing components that run only in the STA does not need to take into account thread synchronization and so On.

The STA contains an invisible window, so the processing of the message queue through the Window's message loop mechanism ensures that only one invocation request is executed at the same time, which is why the component does not need to handle Synchronization.

The MTA is characterized by the ability to have multiple threads running within a suite, and to create new THREADS. Components running in the MTA must implement thread synchronization on their own.

Entrance and exit of the Suite:

The thread enters the suite through the CoInitializeEx function, and the second parameter of the function passes through coinit_apartmentthreaded and coinit_multithreaded to mark the suite Type. If coinit_apartmentthreaded is passed, the thread will create its own private suite, which cannot be accessed by Others. If coinit_multithreaded is passed, the thread will go into the current process-scoped Mta.

The thread calls the CoUninitialize function to exit the suite that is Located. Only after exiting can we enter other types of Suites.

Synchronization of Objects: synchronization of component Objects:

Component objects can be split into single-threaded objects and multithreaded objects, depending on whether multithreading is Supported.

COM object Threading Model:

Each COM object can decide what suite it will run in, which is called the threading model of the COM object.

The component will run in what suite, this is determined by the component developer, the calling component of the client program does not need to care. however, if the calling thread is in a suite that is not in the same suite as the apartment and component, com inserts the Proxy/stub mechanism, and the calling thread invokes the method on the proxy in its own suite, and the object runs in the suite it NEEDS.

Types of In-process object threading Models:

The type of threading model depends on the value of ThreadingModel in the registry----------

1) Both indicates that the component can run in the STA and MTA

2) free indicates that the component can only be run in the MTA

3) apartment indicates that the component can only be run in the STA

4) NULL indicates that the component can only be run in the STA (main Sta) created by the first process.

If the suite of the calling thread satisfies the requirements of the threading model of the In-process component, the Component object is created directly and does not require a proxy.

If the calling Thread's suite does not meet the requirements of the threading model of the In-process component, then COM creates the object in another suitable suite (if there is no suitable suite, COM creates one) and then returns the agent to the calling Thread.

If the component is not in the same process as the client or not on the same machine, it must be in two suites, and COM will create a proxy/stub.

If the threading model of a Component object is both or free, the component must be a multithreaded Object.

If the threading model of the Component object is empty, the component can be either a single-threaded object or a multithreaded Object. The synchronization mechanism inside a multithreaded object is meaningless at this time because there will not be multiple threads accessing the object Simultaneously.

If the threading model of a Component object is apartment, there are two types of things:

A) There are no global variables and static variables inside the component, and the component can be a single-threaded object

B) within the component there are global variables and static variables, the components should be multi-threaded objects, and the global variables and static variables in the

Row Access Protection.

ATL support for Multithreading:

Support for synchronization in COM objects in ATL has its own consideration: if the COM object itself is a single-threaded object that does not consider synchronization, ATL should not synchronize protection for any data members of that object including the object reference variable m_cref. Because synchronous protection is an additional resource-intensive Requirement. The principle in ATL is to only synchronize protection where protection is Needed. This is consistent with the design purpose of atl----everything for Efficiency.

Protection of Object References:

Static member functions increment and decrement are defined inside the ccomsinglethreadmodel, ccommultithreadmodel, and CComMultiThreadModelNoCS Classes. The template parameters of the CComObjectRootEx class accept the above three classes and use their static member functions, and our component implementation classes derive from the CComObjectRootEx class to obtain the ability to synchronize object references based on whether our component supports Multithreading. In a word, we just have to derive the CComObjectRootEx class with the appropriate template Parameters. Our class is as Follows:

Class Atl_no_vtable CMIS:

Public ccomobjectrootex<ccomsinglethreadmodel>

The CMIs class does not need to consider the synchronous protection of object references, because our component objects are single-threaded and the threading model is empty or apartment.

note, however, that the default threading model in the ATL Project's Component Class script is both, which poses a problem, so we manually modify it.

If we change the code as Follows:

Class Atl_no_vtable CMIS:

Public ccomobjectrootex< ccommultithreadmodel, then our Component object reference count is synchronously protected, and our component objects are responsible for the synchronous Protection. So if there are member variables in the CMIs class, then we need to protect the member variables Synchronously.

Protection of member Variables:

Synchronous protection by means of critical section we want to use class Ccommultithreadmodel. Our component implementation classes derive from the ccomobjectrootex< CComMultiThreadModel > class. The method used is extremely simple and we simply add the following code at the beginning of a function that needs to prevent multiple threads from executing concurrently:

Objectlock Lock (this);

If you want to use more than one critical section, it's not that simple, but unless you have to, I don't recommend it because it's easy to cause deadlocks. Be sure to use the words must first read <<windows core programming >> and <<win32 multithreaded programming >> these two books.

Changes caused by COM +: Overview of the Context:

The further expansion of COM + 's concept of suites requires that each object must be run in Context. Controls the thread synchronization of an object through Context.

Suites are subdivided into one or several contexts. A context can only be in one Suite. A suite contains at least one default Context.

Object calls that are located between different contexts in the same suite must go through a lightweight proxy column Set. Lightweight proxies are different from the agents between suites because of the smaller performance Penalty.

A traditional COM component that is not hosted by COM + does not use a lightweight proxy. however, The COM component will be considered to be placed inside the default context of the suite it is living in, and the other context of the suite (if Any) does not require a lightweight proxy for access to the default context, and the introduction of the default context is only intended to be consistent with the concept of the COM + context.

Context Object:

The context object specifically represents each Context. The cogetobjectcontext is used to get the context object where the current object Resides.

The context object exposes iobjectcontextinfo, icontextstate, iobjectcontext, and iobjectcontextactivity four Interfaces. The back two interfaces are backwards compatible with mts, which can be ignored.

The Iobjectcontextinfo::getcontextid method can obtain the context id, which is handy for debugging Purposes. note, however, that only COM components are managed by COM + to get the context object, otherwise cogetobjectcontext will return e_nointerface and return a null interface pointer. So if we are developing components that apply to both COM + and traditional COM two cases, you must query the Cogetobjectcontext return value and make a Distinction.

Call Object:

When a customer calls a COM object through a COM + service, COM + creates a temporary object called "calling object" on behalf of the Customer's call to the COM object. The calling object is destroyed after the method returns.

The calling object exposes two interfaces related to security settings.

The CoGetCallContext function allows the object to get its own calling object, and if it returns rpc_e_call_complete, no customer is currently calling Itself.

category: COM Technology

"reprint" com Multithreading principle and application