Single-Threaded Apartments vs Multi-Threaded Apartments [duplicate]
Asked Answered
H

5

43

Possible Duplicate:
Could you explain STA and MTA?

All ThreadPool threads are in the multithreaded apartment.

--As per the MSDN

What does that mean? I am really concerned with what the difference between the multi vs single threaded apartment model is. Or what does the apartment model mean? I have read the MSDN on it, and it doesn't really make sense to me. I think I may have an idea, but I was thinking someone on here could explain it in plain English.

Thanks, Anthony D

Update 1

Found this Could you explain STA and MTA?

Can anyone be more descriptive?

Update 2

I am also looking for an answer about how this applies to the thread pool, and what I need to watch out for because of this.

Homosexual answered 27/1, 2009 at 20:27 Comment(1)
Great question. I agree, there aren't many straightforward/clear explanations out there!Alfonso
A
57

STA (single-threaded apartment) and MTA (multi-threaded apartment) are to do with COM. COM components can be designed to be accessed by a single thread, in which case it they are hosted in an STA, or they can be made internally thread safe, and hosted in an MTA. A process can have only one MTA, but many STAs. If you're only going to consume COM components all that you really need to know is that you have to match the apartment to the component or nasty things will happen.

Analogue answered 27/1, 2009 at 20:35 Comment(6)
Perfect, thanks for the awesome answer. I guess all that just to figure out I don't need to worry in this case.Homosexual
No worries. IF you're using .Net COM interop then you won't have to think about it most of the time anyway.Analogue
Minor correction, you can have multiple STAs, but only one MTA.Expletive
Doh! Well spotted - fixed now...Analogue
FYI, MTA is the default for .NET threads.Auliffe
@Teomanshipahi Some PowerShell versions have STA as default.Marta
W
12

In actuality, STAs and MTAs have an impact on .NET code. See Chris Brumme's blog entry for way more detail then you probably need:

https://devblogs.microsoft.com/cbrumme/apartments-and-pumping-in-the-clr/

It's really important to understand how STAs pump messages in .NET. It does have consequences.

Woollyheaded answered 28/1, 2009 at 18:26 Comment(0)
I
9

If your COM object needs to believe that it is in a single-threaded environment, use STA. You are guaranteed that the creation and all calls will be made by the same thread. You can safely use Thread local storage and you don't need to use critical sections.

If your COM object can be accessed by many threads simultaneously, use MTA -- there will be no guards put in place.

Isthmian answered 27/1, 2009 at 20:33 Comment(2)
I think Robert C. Barth's answer also applies here then right? "You don't have to worry about it unless you're doing COM-interop, in which case there are marshalling issues. It has no ramifications for .net itself."Homosexual
There are a couple of .Net specific points. The most important is that WinForms or WPF apps must have their main threads in the STA. This is because a lot of the UI functionality is a thin .Net wrapper around COM-implemented controls. Hence the [STAThreadAttribute] on the Main method in .Net apps.Analogue
C
6

As others have pointed out, it generally has little impact on .NET applications.

However, be aware that the Microsoft test host used for unit tests is actually implemented in an STA, which means that there are limitations on what you can do in unit test. For example you cannot do a WaitAll on a WaitHandle in a unit test is you're using Microsoft's test host.

Cultural answered 27/1, 2009 at 20:45 Comment(0)
G
2

You don't have to worry about it unless you're doing COM-interop, in which case there are marshalling issues. It has no ramifications for .net itself.

Griz answered 27/1, 2009 at 20:32 Comment(1)
You don't have to worry until you try to send an HTML print job from a web service using a WebBrowser control. (The "simple" way everyone says to do it.) And then nothing works.Sibell

© 2022 - 2024 — McMap. All rights reserved.