Multithreading model of "reprint" com

The original:multithreaded model of COM

COM's multithreaded model is one of the most incomprehensible parts of COM technology, and many books are involved but not well understood. Many new people will feel very confused here, Google God can search for an article on the vckbase, but the personal advice is not to look good almost nonsense in the mess.

COM does not actually have any multithreaded models, so the multithreaded model he uses is still the set of threads and synchronization objects inside the WIN32. As a preparation, here's a brief talk about WIN32 threads and synchronization. As a convention a WIN32 thread and synchronization object will be the process, thread this two things to say, but not here, because it will look at the COM is already familiar with this part, if not familiar with the suggestion also do not look at COM first look back to see "Windows core Programming" and "Windows advanced programming 》。 WIN32 threads can be divided into two types, the UI thread and the worker thread. The UI thread is a thread that binds to a window, which is characterized by a message loop and a window procedure that contains a window, because the presence of a message loop causes it to inherently have a synchronization mechanism: Any message sent to that thread will be synchronized with the message loop, and no two or more messages will be processed by the window process at the same time , all messages are serialized by the message loop, and the worker thread can be thought of as a function running on one thread, which does not have any synchronization mechanism of its own. If you want to implement some kind of synchronization on two worker threads, you can only use WIN32 synchronization objects such as CriticalSection or event, and so on.

Next look at the multithreaded model of COM, from the VS2005 ATL Engineering Wizard, you can see that the COM multithreading model is divided into the following categories: Single-threaded, Suite (Apartment), both (Both), free. This part of the person feel that translation is not very good, single-threaded (single) personally think the translation into a studio will be better, the reason behind the specific description, but as a respect for the MS Guide or not even more confusing this part, the following terminology refers to the MS Wizard and I use English terminology as far as possible.

You can see the most used two words in the COM multithreaded model is the suite, then explain the suite first. The suite can imagine a room according to his English, the room is surrounded by walls, so to enter this room must be a means to penetrate (through the door or something similar), and this room is placed in one or more COM objects. The more theoretical interpretation of the suite is that there is one or more COM components in a suite, and there is a clear boundary between the suites, and there is only one suite thread in the suite, and this suite thread has a message loop similar to the one that should not actually be used, He is a message loop that hides the window to ensure that it is inherently synchronous. What do you think the suite looks like in this definition? Yes, a Windows window application process with only one main thread. So the suite is a UI thread! As a UI thread, he will naturally be able to complete the synchronization function. This is followed by several parts of the COM threading model.

One, single-thread

As mentioned earlier, this model is best translated into a single suite, because this multithreaded model does not mean that COM components can only be used in a single-threaded program, the opposite component can be used in the normal use of multithreaded programs. The real meaning of this model is that even if your program is multithreaded and you call Coinitalize (0,coinit_apartment) in every thread, you actually create only one suite in your program process, And put all the components in this suite, and this suite has a message loop to ensure synchronization.

This may not be comprehensive, but the above paragraph does say one of the simplest cases in which all components are created as a single model. If this is not the case, for example, A, B, C three components are created as a single model, D is created by the apartment model, and four components are created on the TA, TB, TC, TD four lines thread (each thread calls Coinitalize (0, Coinit_apartment) to create the environment, then components A, B, C run in the suite created by Ta (TB, TC did not create a suite, TA is the suite thread), and component D is run independently in the TD-created Suite (TD is the suite thread), There's a total of two suites here. This should be a complete situation, and then the complicated situation I think you can be introduced.

Second, Suite (Apartment)

This model is similar to the previous model and can all be thought of as creating a WIN32 conceptual UI thread, but the difference is that the single model no matter how many lines thread you call Coinitalize (0,coinit_apartment) creates only one suite, Suite Suite Thread is the first time you call Coinitalize (0,coinit_apartment) thread, and APARTMENT model is you on a thread to raise a coinitalize (0,coinit_apartment) Create a suite and use the thread as a suite thread.

Iii. Freedom (free)

This model is a worker thread, and COM no longer uses the message loop to provide a synchronization mechanism. You have to use it in multiple threads, OK, and you do it yourself (or the component developer makes the component thread-safe). You need to use it in one single thread, and that's better anyway, it doesn't have to be synchronized.

Iv. Both (Both)

This model ensures that components can be used in suite models as well as in free models. For example, if the component itself is created as apartment or single, but the consumer creates the environment with Coinitalize (0,coinit_mulitithread), then COM will create another thread with Coinitalize (0, Coinit_apartment) to create an environment for the component to run, and vice versa.

Finally, the question of cross-suite calls, from the above description can be seen in the two models of single and apartment in the suite call or through the COM mechanism of communication between the suite is synchronized, but how to call across the suite, for example, we often do this kind of thing, Pass an interface pointer that exists in the suite as a thread parameter to another thread, or two components exist in different suites, but are called to each other because of connection points or callbacks. At this point we need to use the proxy/stub mechanism to call the Comashalinterthreadinterface function before passing the interface pointer (I guess this is the longest function in all Win32API, Ms really doesn't make a good day-.-| | | ) to wrap the interface pointer to the PS DLL to pass, and then the calling thread or suite to use Cogetinterfaceandreleasestream to regain the interface pointer passed through, so that the COM thread synchronization mechanism can be run properly.

Well, it's all over, if it's not clear to suggest a look at the 12th chapter in "COM Tech Insider", this book is the best one I've ever seen in all of the books (better than the ATL insider), especially the ones inside, which are very helpful in understanding these models, which are available electronically on the web.

Multithreading model of "reprint" com