Implementation of MTA COM server

2
votes

I can't find any source code on the prerequisites of an MTA compliant COM. I tried changing the ThreadingModel registry key of my object from Apartment to Both, and it results in a crash when a secondary thread calls the method before any data is accessed.

If STA COMs require a message pump, what kind of plumbing code do MTA COM objects require?

1
winapicommta
What is the call stack of the crash? – wilx
There is no boiler-plate code ever for a class that's guaranteed thread-safe. That needs to be done the hard way, use locking primitives to ensure that a method of your COM server can be called by an arbitrary thread at an arbitrary time and cannot corrupt the state of your object. – Hans Passant
@VáclavZeman: it's complicated, as they say. The COM itself has been built using an obscure language called Clarion, which has no ability to debug COMs. The .NET wrapper does not go that far. – Vadim Berman
@HansPassant: like I said, it crashes before it even touches anything and there are mutexes and semaphores everywhere. – Vadim Berman
Nevermind. The issue was Clarion-specific need to re-link new threads since even primitives in their runtime library involve thread specific memory allocation. – Vadim Berman

1 Answers

4
votes

I do not think that there is anything special about MTA, except that you need to use synchronization primitives like mutexes to synchronize access to your internal structures. Does the "Multithreaded Apartments" not give you all that you need?

Quoting from the documentation, emphasis is mine:

Because calls to objects are not serialized in any way, multithreaded object concurrency offers the highest performance and takes the best advantage of multiprocessor hardware for cross-thread, cross-process, and cross-machine calling. This means, however, that the code for objects must provide synchronization in their interface implementations, typically through the use of synchronization primitives such as event objects, critical sections, mutexes, or semaphores, which are described later in this section. In addition, because the object doesn't control the lifetime of the threads that are accessing it, no thread-specific state may be stored in the object (in thread local storage).