24.9 Controlling Managed Thread Apartment States

You want to use a specific threading model in your .NET application when using COM interop.

Technique

COM contains a complex threading model that allows for safe object access in general cases or complete multithreaded access for objects that support direct synchronization. Each thread and object that is created in the COM world is placed into an apartment. An apartment is a special threading model explained later. Because a .NET application can create and utilize COM objects, it too must be placed into an apartment. The two possible apartment models available for .NET application include the single-threaded apartment (STA) and the multithreaded apartment (MTA). You can specify the apartment that your application uses by using either the STAThread or the MTAThread attribute on the application's entry point. The other method is to change the Thread.CurrentThread.ApartmentState property by specifying a value from the ApartmentState enumerated data type. Both options appear in Listing 24.3.

Listing 24.3 Changing .NET Apartment States

 using System; using System.Threading; namespace _9_ThreadStateMTA {     class Class1     {         [MTAThread]         static void Main(string[] args)         {         }     } } using System; using System.Threading; namespace _9_ThreadStateSTA {     class Class1     {         static void Main(string[] args)         {             Thread.CurrentThread.ApartmentState = ApartmentState.STA;         }     } } 

Comments

By now you've probably seen the STAThread attribute defined on some of your application's entry points because it is automatically applied during project creation. If you never plan on using COM interop within your application, this attribute becomes unnecessary and you can safely remove it.

An apartment is a conceptual entity designed to control how concurrent access to an object should be handled. The two main apartment models supported by .NET include the STA and the MTA. An STA can contain only one thread but any number of contained objects. If a STA is created and it is the only STA present at that time, it is called the main STA. Any other thread that wants to use the object within the main STA is therefore placed in its own STA, and any calls into the object must be marshaled using a proxy to marshal the data and a stub to unmarshal the data before the call is made on the object. The main benefit of using an STA is that an object must service only a single thread at a time. Because Windows services a single message at a time from its message queue, the STA model uses a hidden window to ensure that object calls are placed within a queue to be serviced one at a time.

An MTA, on the other hand, contains several threads, each interacting with multiple objects. With the STA model, an application contains multiple STAs, each containing a thread, but the MTA model uses only a single apartment. Additionally, the object can service multiple calls at a time coming from different threads, which means the object must ensure proper synchronization to its resources to avoid data corruption.

If the previous discussion left you in the dark (which can happen quite often when talking about apartments), then the following real-world analogy might help. Let's assume that a bank represents a process. Each bank teller within the bank represents a COM object, and each customer represents a calling thread. In an STA model, the customers line up and wait their turn to talk to a bank teller. When a bank teller finishes servicing a request, the serviced customer leaves and the next customer can use the bank teller. With the MTA model, a customer can interrupt the bank teller currently servicing another customer to perform a transaction. At this point, two customers are using the same bank teller, and if the bank teller isn't careful, the transactions can get mixed up.

Based on the analogy, you might automatically assume that using the STA model is more desirable because concurrent access is handled by the unforeseen force that keeps customers in the line and waiting their turn. However, which method do you think would have better performance? Assuming the tellers are good at multitasking and will not mix up concurrent transactions, the line of serviceable customers diminishes more quickly than if a queue were used. As we've said repeatedly throughout this book, the decision must based on the design decisions you make for your application.