COM and Multithreading

[Theo Gottwald]

I think the next big Bang besides x64 is Multithreading.
The reason comes from the same corner:

Intel has announced the first 50-Core CPU's.
For Servers first ... but some time later then they will be anywhere,
if its not a Netbook.

Multithreading is the Nr.2 big Bang.

Therefore i have a question, maybe somebody has take a look on this before.
There are different Multithreding Models using COM.

Looking at this, i would say that a adress i got with Query Interface is in the adress space of CPU Nr.1.

Thats why I would like to know:

Is there any chance, to use an interface Adress i got using "Query Interface" in a second thread - for example to release it?

[Mike Stefanik]

Any interface pointers that you want to use across apartment boundaries need to be marshalled; just storing an interface pointer in a global variable should never be done unless you know that both objects use MTAs (and the vast majority of ActiveX controls out there use STAs). Frankly, multithreading with COM is kind of a mess, and it can get pretty complicated. The rules of thumb when creating a COM server are:

1. Access to global and static variables shared between multiple objects (e.g.: if you have multiple COM objects in your DLL) should always be synchronized using critical sections, the interlocked APIs, etc. regardless of which threading model is used.

2. If the COM object uses the STA (single threaded apartment) model, method calls are serialized but if you want to hand your interface pointer to another object, you need to serialize it using the global interface table or some ridiculously long COM API function I can't recall offhand. You also need to make sure that you have a message pump, because the way that those method calls are serialized is through the Windows message queue.

3. If the COM object uses the MTA (multithreaded apartment) model, then in addition to synchronizing access to globals and statics, you also need to synchronize access to the object's class instance/member variables because method calls are not serialized and it's possible that you can get multiple calls invoked concurrently on different threads. In other words, a COM object that uses MTA must be fully thread-safe.

Edit: I'd also just point out that it's a mistake to think in terms of address space in the context of a particular thread (all threads in a process have access to the address space of that process), or in terms of threads running on a particular processor. Unless you explicitly specify affinity, Windows can schedule a thread to execute on any processor that it chooses.

[Theo Gottwald]

I'd also just point out that it's a mistake to think in terms of address space in the context of a particular thread (all threads in a process have access to the address space of that process), or in terms of threads running on a particular processor

Ok, that was the important point i did not realize properly.
Of course you are right. Just another process can not touch another processes memory!

The synchronisation in Multitaksing environments is something i did already in the past.
It will be of increasing importance in the future.

Computerprogramms/software are making the step to "industrial age" soon.

Until now most "Jobs" were done by a single CPU (person).
Since the industrial age, multiple person (CPU)'s) work at the same time on a single subject and produce together things a lot faster.

COM must be usable in these circumstances also.