I've come across this problem several times while developing in C#. I'll be a happily coding along, passing objects to and fro between threads and what not, then all of a sudden I get this familiar error:
"The calling thread cannot access this object because a different
thread owns it."
Well, ok, I've dealt with it before, especially with objects on the GUI thread. You just have to write some extra code to program around that specific problem. But every once in while I come across an object that is by all means ordinary, yet it doesn't like being accessed by different threads.
EDIT I was mistaken in my original post about the object that was causing the access exception. It was NOT IPAddress, instead its System.Printing.PrintQueue. which I was using to obtain the IP address. This is the object that you can't assess from more than 1 thread.
All my classes I've written never have this problem. I don't even know how I'd implement this myself. Would you have to keep a member variable with the thread ID that created you, and then check the current thread against that on every single property and method access? That seems crazy. Why would Microsoft decide that..... "OK... PrintQueue, definitely not sharable among threads. But these other classes.... their good to go."
Why are some objects blocked from multiple thread access?
I think this may explain things fairly well, I think this specifically has to do with COM.
http://msdn.microsoft.com/en-us/library/ms693344%28v=vs.85%29
specifically.
In general, the simplest way to view the COM threading architecture is
to think of all the COM objects in the process as divided into groups
called apartments. A COM object lives in exactly one apartment, in the
sense that its methods can legally be directly called only by a thread
that belongs to that apartment. Any other thread that wants to call
the object must go through a proxy.
There are two types of apartments: single-threaded apartments, and
multithreaded apartments.
Single-threaded apartments consist of exactly one thread, so all COM objects that live in a single-threaded apartment can receive
method calls only from the one thread that belongs to that apartment.
All method calls to a COM object in a single-threaded apartment are
synchronized with the windows message queue for the single-threaded
apartment's thread. A process with a single thread of execution is
simply a special case of this model.
Multithreaded apartments consist of one or more threads, so all COM objects that live in an multithreaded apartment can receive method
calls directly from any of the threads that belong to the
multithreaded apartment. Threads in a multithreaded apartment use a
model called free-threading. Calls to COM objects in a multithreaded
apartment are synchronized by the objects themselves.
Related
I'm trying to understand C# thread apartments and have questions:
What exactly apartment is and what it contains?
The Apartment and the COM Threading Architecture
A process can have zero or more single-threaded apartments and zero or one multithreaded apartment.
Could anybody provide C# code-sample example or explanation for app, where are:
0 of STAs, 0 of MTAs
1 of STAs, 0 of MTAs
2 of STAs, 0 of MTAs
0 of STAs, 1 of MTAs
1 of STAs, 1 of MTAs
2 of STAs, 1 of MTAs
And when each case should\can be used?
A COM apartment is a logical concept. An apartment contains threads. An STA apartment can only contain one thread (hence the name "single threaded apartment"). An MTA can contain many threads (hence the name "multi threaded apartment"). Since an MTA can contain as many threads as it likes, there is at most one MTA in a process.
You can easily write these samples yourself. Just create threads in C#, and at the beginning of the thread entrypoint method, call Thread.SetApartmentState. Any threads you set to be MTA will live in the single MTA; any threads you set to STA will each live in their own STA.
Don't try to fiddle with a threadpool thread's apartment state. Those threads are shared (it's a pool), so it's not nice to be trying to change how they work. Also, once a thread belongs to an apartment, it cannot be changed.
Oh, I almost forgot to answer "when each case can / should be used": never, if you can help it.
Even when writing COM objects, I've always preferred to write "free-threaded" objects (that don't care what apartment they are in), but I can do that, because I have the superpower of understanding threads and knowing how to use a mutex. The threading model was created because (or at least in part because) many early semi-pro VB developers did not understand these concepts (maybe still don't?), and so COM people tried to come up with a system that would still let them easily do thready things.
So what happens when you try to pass a COM object from one apartment to another is that it has to go through special (annoying) magic to be marshaled; and even to make a call from one apartment to another has to go through special (annoying) magic. This is where all the jazz about proxies and stubs comes in. If you want to learn how all that stuff works, well... you know where the documentation is. But if you don't have to use it for some reason (like interop with existing COM objects), just avoid it if at all possible.
Additional questions from comments:
we can set apartment for thread, using Thread.SetApartmentState for a thread or [STA\MTAThread] attribute for method. But can we get\set apartment for objects?
No. A COM object belongs to the apartment it was created in, the end.
all calls to object which was created in STA apartment by its thread should be performed by this thread.
For objects that belong to the STA: Yes and no. "No" is because due to the special (annoying) magic that I referred to earlier (proxies and stubs), you can get a reference to a COM object belonging to STA#1 over on a different thread in STA#2, and make a call on it from there. "Yes" is because what happens under the hood is the proxy/stub magic sends a message from one thread to the other, and the method actually does always execute on the thread that the object belongs to. So you can /initiate/ a cross-apartment call from any thread... but the method itself will execute on the thread that the object belongs to. A problem that often comes up is that for one reason or another, the proxy/stub magic is not available for a given COM object... in which case you are stuck; you really can only use that object directly on the thread where it lives.
For MTA, it's a little looser--the special (annoying) marshaling stuff only comes into play when crossing apartment boundaries, not thread boundaries. So you have to be careful about handling synchronization yourself if you have multiple threads in your MTA.
I have a component registered in Castle Windsor as a singleton. This object is being used in many other places within my application which is multithreaded.
Is it possible that the two objects will invoke the same method from that singleton at the same time or 'calling it' will be blocked until the previous object will get result?
Thanks
You can call a Singleton object method from different threads at the same time and they would not be blocked if there is no locking/ synchronization code. The threads would not wait for others to process the result and would execute the method as they would execute methods on separate objects.
This is due to the fact that each thread has a separate stack and have different sets of local variables. The rest of the method just describes the process as to what needs to be done with the data which is held the variables/fields.
What you might want to take care of is if the methods on the Singleton object access any static methods or fields/variables. In that case you might need to work on synchronization part of it. You would need to ensure multi-threaded access to shared resources for the execution of the method to be reliable.
To be able to synchronize, you might need to use lock statement or other forms of thread synchronization techniques.
You might want to refer to this article from Wikipedia which provides information on C# thread local storage as well.
You can call the same method or different methods on one object simultaneously from different threads. In the specific methods you'll need to know when sensitive variables are being accessed (mostly when member-variables are changing their values) and will need to implement locking on your own, in order to solve lost updates and other anomalies.
You can lock a part of a code with the lock-statement and here an article on how Thread-Synchronization works in .Net.
The normal version of Singleton may not be thread safe, you could see different implementation of thread safe singleton here.
http://tutorials.csharp-online.net/Singleton_design_pattern:_Thread-safe_Singleton
Although there are many questions about COM and STA/MTA (e.g. here), most of them talk about applications which have a UI. I, however, have the following setup:
A console application, which is by default Multi-Threaded Apartment (Main() explicitly has the [MTAThread] attribute).
The main thread spawns some worker threads.
The main thread instantiates a single-threaded COM object.
The main thread calls Console.ReadLine() until the user hits 'q', after which the application terminates.
A few questions:
Numerous places mentions the need of a message pump for COM objects. Do I need to manually create a message-pump for the main thread, or will the CLR create it for me on a new STA thread, as this question suggests?
Just to make sure - assuming the CLR automagically creates the necessary plumbing, can I then use the COM object from any worker thread without the need of explicit synchronization?
Which of the following is better in terms of performance:
Let the CLR take care of the marshaling to and from the COM object.
Explicitly instantiate the object on a separate STA thread, and have other thread communicate with it via e.g. a ConcurrentQueue.
This is done automagically by COM. Since your COM object is single-threaded, COM requires a suitable home for the object to ensures it is used in a thread-safe way. Since your main thread is not friendly enough to provide such guarantees, COM automatically creates another thread and creates the object on that thread. This thread also automatically pumps, nothing you have to do to help. You can see it being created in the debugger. Enable unmanaged debugging and look in the Debug + Windows + Threads window. You'll see the thread getting added when you step over the new call.
Nice and easy, but it does have a few consequences. First off, the COM component needs to provide a proxy/stub implementation. Helper code that knows how to serialize the arguments of a method call so the real method call can be made on another thread. That's usually provided, but not always. You'll get a hard to diagnose E_NOINTERFACE exception if it is missing. Sometimes TYPE_E_LIBNOTREGISTERED, a common install problem.
And most significantly, every call on the COM component will be marshaled. That's slow, a marshaled call is usually around 10,000x slower than a direct call on a method that itself takes very little time. Like a property getter call. That can really bog your program down of course.
An STA thread avoids this and is therefore the recommended way to use a single-threaded component. And yes, it is a requirement for an STA thread to pump a message loop. Application.Run() in a .NET program. It is the message loop that marshals calls from one thread to another in COM. Do note that it doesn't necessarily mean that you must have a message loop. If no call ever needs to marshaled, or in other words, if you make all the calls on the component from the same thread, then the message loop isn't needed. That's typically easy to guarantee, particularly in a console mode app. Not if you create threads yourself of course.
One more nasty detail: a single-threaded COM component sometimes assumes it is created on a thread that pumps. And will use PostMessage() itself, typically when it uses worker threads internally and needs to raise events on the STA thread. That will of course not work correctly anymore when you don't pump. You normally diagnose this by noticing that events are not being raised. The common example of such a component is WebBrowser. Which heavily uses threads internally but raises events on the thread on which it was created. You'll never get the DocumentCompleted event if you don't pump.
So putting [STAThread] on your Main() method might be enough to get happy fast code, even without a call to Application.Run(). Just keep the consequences in mind, seeing a method call deadlock or an event not getting raised is the tell-tale sign that pumping is required.
Yes, it is possible to create a STA COM object from an MTA thread.
In this case, COM (not CLR) will create an implicit STA apartment (a separate COM-owned thread) or re-use the existing one, created ealier. The COM object will be instantiated there, then a thread-safe proxy object (COM marshalling wrapper) will be created for it and returned to the MTA thread. All calls to the object made on the MTA thread will be marshalled by COM to that implicit STA apartment.
This scenario is usually undesirable. It has a lot of shortcomings and may simply not work as expected, if COM is unable to marshal some interfaces of the object. Check this question for more details. Besides, the message pump loop, run by the implicit STA apartment, pumps only a limited number of COM-specific messages. That may also affect the functionality of the COM.
You may try it and it may work well for you. Or, you may run into some unpleasant issues like deadlocks, quite difficult to diagnose.
Here is a closely related question I just recently answered:
StaTaskScheduler and STA thread message pumping
I'd personally prefer to manually control the logic of the inter-thread calls and thread affinity, with something like ThreadAffinityTaskScheduler proposed in my answer.
You may also want to read this: INFO: Descriptions and Workings of OLE Threading Models, highly recommended.
Do I need to manually create a message-pump for the main thread,
No. It is in the MTA therefore no message pump is needed.
or will the CLR create it for me on a new STA thread
If COM creates the thread (because there is no STA in the process) then it also creates the message pump (and a hidden window: can be seen with the SPY++ and similar debugging tools).
COM object from any worker thread without the need of explicit synchronization
Depends.
If the reference to the single threaded object (STO) was created in the MTA then COM will supply the appropriate proxy. This proxy is good for all threads in the MTA.
In any other case the reference will need to be marshalled to ensure it has the correct proxy.
is better in terms of performance
The only answer to this is to test both and compare.
(Remember if you create the thread for the STA and then instantiate the object locally you need to do the message pumping. It is not clear to me that there is any CLR level lightweight message pump—including WinForms just for this certainly isn't.)
NB. The only in depth explanatory coverage of COM and the CLR is .NET and COM: The Complete Interoperability Guide by Adam Nathan (Sams, January 2002). But it is based on .NET 1.1 and now out of print (but there is a Kindle edition and is available via Safari Books Online). Even this book doesn't describe directly what you are trying to do. I would suggest some prototyping.
Extension to Release COM Object in C#
I noticed that saving the MailItem and releasing is a time consuming task. So, it is safe to do the following ? (pseudo-code below)
Thread 1 (main thread)
- Open 10 (different .msg files) - MailItems [List<MailItem> items]
- user works on them and want to save and close all of them with one click.
- On_save_All_click (runs on main thread)
- Do
- toBeClearedList.addAll(items);
- items.clear() [so that main thread cannot access those items]
- BG_Thread.ExecuteAsyn(toBeClearedList);
- End
Thread 2 (background thread) (input - List<MailItems>)
- foreach(MailItem item in input)
item.save();
System.Runtime.InteropServices.Marshal.ReleaseComObject(item)
- done
I wrote couple of tests and looks like its working; Just want to know if its safe to do so ? "Releasing COM objects in different thread than the one in which it was created"
Thanks
Karephul
When using COM from unmanaged code (C/C++), the rules are pretty strict: you can only call methods on an interface from the same apartment that you acquired the object on. So if you obtain an interface pointer on an STA thread, then only that thread is allowed to call any of the methods. If you obtain an interface pointer on an MTA thread, then only other threads in the same MTA can use that pointer. Any other use that crosses apartments requires that the interface pointer is marshaled to the other apartment.
However, that's unamanged world. .Net adds a whole layer on top of COM which buries a lot of these low-level details, and for the most part, once you get your hands on an interface, you can pass that interface around between threads as much as you please without having to worry about the old threading rules. What's happening here is that it are actually passing around references to an object called a "Runtime Callable Wrapper" (RCW), and it is managing the underlying COM interface, and controlling access to it accordingly. (It takes on the burden of upholding the COM apartment rules so that you don't have to, and that's why it can appear that the old COM threading rules don't apply in .Net: they do, they're just hidden from you.)
So you can safely call Release or other methods from another thread: but be aware that if the original thread was STA, then calling those methods will cause the underlying RCW to marshal the call back to the original owning thread so that it still upholds the underling COM rules. So using a separate thread may not actually get you any performance in the end!
Some articles worth reading that fill in some of the details here:
The mapping between interface pointers and runtime callable wrappers (RCWs) - good overview of some of the details of how RCW's work, but it doesn't say much about threading.
Improving Interop Performance - Marshal.ReleaseComObject - some good notes on when to use or not use ReleaseComObject, and how it works with the RCWs.
cbrumme's WebLog - Apartments and Pumping in the CLR - more internals than you're likely to want to know; this is a couple of CLR releases out of date, but still gives a good insight into how .Net covers over many of the underlying COM issues.
If I remember my COM properly (I always hated that technology, way too complicated), if the COM object is single-threaded (that is, belongs in a single-threaded-apartment), releasing it from another thread isn't going to do you any good - it's just going to execute the actual release code in your main thread.
You are going to see a little difference between your code, and releasing the objects from the main thread in one loop. If you release the objects in one loop, your UI is going to be unresponsive until you release all messages. By using a secondary thread, your UI thread will release one message, then handle other events, then release another, and so on. You can get the same effect by sending yourself a message (or using a Dispatcher if you have a WPF application), and avoid having another thread.
From the MSDN article on STAThread:
Indicates that the COM threading model for an application is single-threaded apartment (STA).
(For reference, that's the entire article.)
Single-threaded apartment... OK, that went over my head. Also, I read somewhere that unless your application uses COM interop, this attribute actually does nothing at all. So what exactly does it do, and how does it affect multithreaded applications? Should multithreaded applications (which includes anything from anyone using Timers to asynchronous method calls, not just threadpools and the like) use MTAThread, even if it's 'just to be safe'? What does STAThread and MTAThread actually do?
Apartment threading is a COM concept; if you're not using COM, and none of the APIs you call use COM "under the covers", then you don't need to worry about apartments.
If you do need to be aware of apartments, then the details can get a little complicated; a probably-oversimplified version is that COM objects tagged as STA must be run on an STAThread, and COM objects marked MTA must be run on an MTA thread. Using these rules, COM can optimize calls between these different objects, avoiding marshaling where it isn't necessary.
What that does it it ensures that CoInitialize is called specifying COINIT_APARTMENTTHREADED as the parameter. If you do not use any COM components or ActiveX controls it will have no effect on you at all. If you do then it's kind of crucial.
Controls that are apartment threaded are effectively single threaded, calls made to them can only be processed in the apartment that they were created in.
Some more detail from MSDN:
Objects created in a single-threaded
apartment (STA) receive method calls
only from their apartment's thread, so
calls are serialized and arrive only
at message-queue boundaries (when the
Win32 function PeekMessage or
SendMessage is called).
Objects created on a COM thread in a
multithread apartment (MTA) must be
able to receive method calls from
other threads at any time. You would
typically implement some form of
concurrency control in a multithreaded
object's code using Win32
synchronization primitives such as
critical sections, semaphores, or
mutexes to help protect the object's
data.
When an object that is configured to
run in the neutral threaded apartment
(NTA) is called by a thread that is in
either an STA or the MTA, that thread
transfers to the NTA. If this thread
subsequently calls CoInitializeEx, the
call fails and returns
RPC_E_CHANGED_MODE.
STAThread is written before the Main function of a C# GUI Project. It does nothing but allows the program to create a single thread.