1

I think I understand the apartment concept and why STA or MTA is used, however a question came up for which I found no solution so far.

If my application uses COM Objects under the hood, for example from third party libraries, how do I know if I can use MultiThreaded-Appartment (MTA)? In that case, I have no Idea if those objects are thread safe, so do I need to go with STA, just to be on the safe side?

DanielG
  • 1,217
  • 1
  • 16
  • 37

2 Answers2

2

Your ability to use certain COM interface pointer on STA or MTA thread code depends on whether you at all cab obtain this pointer on this thread. If you can get the point on STA (or MTA) thread - you are good to use it further, provided that you don't pass it directly to another apartment.

If COM server is registered in certain way that you cannot obtain a pointer due to apartment type mismatch (typical case: STA thread and COM server is registered using "free" apartment model) then COM will attempt to marshal the pointer for you. If marshaling is successful, your code receives the pointer and you are good to go from there. Otherwise you get an error, and your attempt to do the same from another apartment succeeds. Basically, this is the only reliable generic method to obtain the answer on being able to use specific COM interface on STA or MTA thread.

In more specific case of instantiating a COM object, you can look up its registry information to see whether instantiation matches your apartment type. Out-of-process servers will provide you COM interface pointers through marshaling in any event, so any client side apartment will be able to consume this server.

There is no question of whether server objects are thread safe. If their COM registration is correct (esp. that STA in-proc server does not announce Free/Both registration) and marshaling is available, thread safety is included for free.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • Thanks! I do not understand every point, since I'm not deep into COM related stuff. I'm not using any COM Objects at all, but some code seems to use COM under the hood. For example, I got a blocked Finalizer, because vb.net uses STA as default and the message loop was blocked by thread.Sleep. I want to make sure, that I safely can just switch to MTA (which is default in c#) and no more care about it afterwards ;). But after a lot of investigation, I'm still not sure if this may break my code somehow!? – DanielG Jan 05 '15 at 16:27
  • 1
    COM's rule is that you don't pass directly pointer between apartments (which typically means that in STA thread you cannot take a pointer outside of this thread, and you can pass pointers between MTA threads but not outside into STA thread). You need to keep this in mind when you are dealing with COM interfaces from VB.NET code. .NET runtime does additional checking and protects from misuse of pointers, so any step aside is likely to result in exception. – Roman R. Jan 05 '15 at 16:32
1

Registered COM objects will belong to an apartment according to the ThreadingModel field (there's another article about COM apartments with a bigger, perhaps simpler table).

Basically, the ThreadingModel tells to which apartment the newly created object will belong to:

  • Not specified

    Main STA (the first CoInitialized STA; if none exists, COM creates one, called the host STA)

  • Apartment

    An STA (if we're in an STA, it'll be it, otherwise the host STA)

  • Free

    An MTA (if we're in the MTA, it'll be it; otherwise, COM creates it, called the host MTA)

  • Both

    Whatever is the current apartment

  • Neutral

    The neutral apartment

If you might be using MTA objects and you doubt if they're "thread-safe" (this typically means it will use an instance level lock on each method/property call), then you can't really do much about it. For instance, you could have multiple STAs accessing the same MTA object concurrently.

Making calls from an STA doesn't necessarily give you this thread safety, unless you guarantee there are no other STAs and no one else is using the same objects.

The "guarantee" works the other way around: all calls made to an STA will be sequential. Even so, re-entrant calls are allowed while the STA makes an inter-apartment call, so this is not really a lock-like guarantee.

The call serialization is really coarse, because it's at the apartment level, so all calls to the same STA, no matter the object, will be executed one at a time (but possibly one over the other in a re-entrant way).

EDIT: Call re-entrancy can be controlled with an IMessageFilter.

acelent
  • 7,965
  • 21
  • 39