First of all, if each thread creates and uses it's own copy of the
COM object then STA is just fine, no penalty will occur unless you
access an object instance from a thread other than the one on
which the object was created.

Also, STA/MTA is a COM thing and can be specified in the native
app, but don't ask me how. Of course, your object needs to be

[quoted text, click to view]


How does your client initialize COM on those threads? Managed classes
registered for COM interop are set to ThreadingModel = Both, so they
should happily enter the MTA.


Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

[quoted text, click to view]

A process can have multiple STA's, so I was assuming you have
one STA per thread. Actually, I'm used to this being the default
behavior at least for STA threads created in VB.NET or C#. I'm
actually not very familiar with the internals of COM, I just
know that using multiple COM objects in multi-threaded C#
applications with STA threads works fine without blocking

That was exactly my problem. Here is how to resolve it...

An exported managed server (COM Object) with a type library registered by
the Assembly Registration tool (Regasm.exe) has a ThreadingModel registry
entry set to Both. This value indicates that the server can be activated in a
single-threaded apartment (STA) or a multithreaded apartment (MTA). The
server object is created in the same apartment as its caller.

Because the client and server are in the same apartment, the interop
marshaling service automatically handles all data marshaling.

Thus, you can use the CoInitializeEx(NULL, COINIT_MULTITHREADED) from your
native thread to ensure that the objects are created in MTA. (Please make
sure that CoInitializeEx() is called at the earliest point in the execution
of the thread, with a matching CoUninitialize at the end.)



[quoted text, click to view]