PC Review
Forums
Newsgroups
Microsoft DotNet
Microsoft C# .NET
difference between STA and MTA
Forums
Newsgroups
Microsoft DotNet
Microsoft C# .NET
difference between STA and MTA
![]() |
difference between STA and MTA |
|
|
Thread Tools |
Rating:
|
|
|
#11 |
|
Guest
Posts: n/a
|
"Applications" are not STA or MTA. *Threads* elect which kind of apartment they want to enter by the call to CoInitialize(Ex).
If a thread elects to join the MTA then it lives with all the other threads that are in the MTA. If it elects to be in an STA then it gets its own encapsulated environment where it is the only thread operating. Objects state which kind of apartment they wish to live in. They do this via the ThreadingModel registry value under the InprocServer32 key. If they elect to live in the MTA they can be accessed by any MTA thread directly at any time so they have to be threadsafe. If they elect to live in an STA then they neter an encapsulated environment where only one particular thread will access them. So putting these two together (I'm purposefully ignoring the Neutral apartment as it doesn't really contribute much to this discussion). If an MTA thread creates an MTA object it gets direct access to the object with no marshalling If an STA thread creates an STA object it gets locaded into the threads STA and theh thread gets direct access to the object with no marshalling If an STA thread creats an MTA object then they live in separate apartments and a call from the STA thread must be marshalled to an MTA thread so the object can be invoked If an MTA thread creates an STA the object gets loaded into a special STA called the Host STA. ALl calls from the MTA thread must get marshalled on to the host STA's thread so teh object can be invoked HTH Regards Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk hi joakim wow, thats a large post... thank you for your answer. |
|
|
|
#12 |
|
Guest
Posts: n/a
|
oh, i see. with MTA/STA you just defines in which "room" your thread is
located. with MTA the thread is going to the "public room" and with the STA the thread is going to his "own room" where just he and his STA child threads can speak together... correct? so the difference between STA and MTA is just the "speaking" with each other in the form of a message pump? if thats correct, i'm close to understand it. however i can hardly think of any explicit example where i can or have to use MTA then? an app which opens and controls the Excel (for example) can be in STA and i can communicate with the created object without any problems. can you tell me an example where i can see the use of it? thanx very much, regards, jazper |
|
|
|
#13 |
|
Guest
Posts: n/a
|
Jazper Manto wrote:
> oh, i see. with MTA/STA you just defines in which "room" your thread is > located. with MTA the thread is going to the "public room" and with the STA > the thread is going to his "own room" where just he and his STA child > threads can speak together... correct? so the difference between STA and MTA > is just the "speaking" with each other in the form of a message pump? > Close, the analogy of the MTA as a public room is a good one, change that to a 'public apartment' and you get the naming. However, there can only be one thread per STA. Communication between threads that each live in STA's must still be marshalled. Every thread that calls CoInitializeEx(COINIT_MULTITHREADED) ends up in the same apartment and can communicate with each other directly. Every thread that calls CoInitialize() or CoInitialize(COINIT_APARTMENTTHREADED), which is the same thing, ends up in a *new* STA. All cross apartment communication must be marshalled and this includes communication between different STA's. > if thats correct, i'm close to understand it. however i can hardly think of > any explicit example where i can or have to use MTA then? > an app which opens and controls the Excel (for example) can be in STA and i > can communicate with the created object without any problems. If you are using an object that is marked as being able to live in the MTA, and you want to use that object from multiple threads, you will be able to use that object without having to marshal every call to and from that object, and, as Richard said, the performance gain is anything but trivial. Some objects may even be marked as MTA-only, in which case you have to create them from another MTA thread if you don't want marshalling to get in the way. |
|
|
|
#14 |
|
Guest
Posts: n/a
|
> Some objects may even be marked as MTA-only, in which case you have to
> create them from another MTA thread if you don't want marshalling to get > in the way. thank you again for your quick and good explained answer! so the communication between public appartment and the threads own appartment is called marshalling. as far as i understand is marshalling like a telephone between own appartment and public appartment. the only difference between public and own apparment is that it costs performance to "call" to the other "room". or the other thing you said is that some objects are marked as MTA only and can not talk to the phone to communicate with the private appartment. so you have to create some kind of a dragoman in the public appartment which can speak directly to that object and give answer to the private appartment... is that analogy correct? if yes, here my last question to understand the situation: you said, when i have a thread in the STA which wants to communicate with an object in the MTA (not marked as MTA only!), it has to be marshalled... who is doing that marshalling between the appartments? the compiler, the OS or do i have to do that on my own? are there any windows APIs which i can do the that, if i have to do the marshalling on my own? regards, jazper |
|
|
|
#15 |
|
Guest
Posts: n/a
|
Couple of things.
There is no concept of a "public apartment". Every thread must enter an apartment when it performs COM work - thats what the call to CoInitialize(Ex) is for. So a thread initializes itself into its own STA or it joins the proces-wide MTA. COM types declare their apartment type via their ThreadingModel value under the InprocServer32 key in the registry this can take the following values Apartment - the objects will be created in an STA Free - the object will be created in the MTA Neutral - the object will be created in the neutral apartment (we can probab ly forget about this one for this discussion) Both - the object will be created in the apartment of the thread that creates the object (STA or MTA) <absent> if this value is not there the object will be created in the first STA created in the process (known as the Main STA) So lets look at a few scenarios: STA thread creates STA object: the object is created in the threads STA, there is no marshalling and all calls to the object are made on the STA thread. MTA thread creates MTA object: the object is created in teh MTA, there is no marshalling and the objects methos run on random threads STA thread creates MTA object: The object is created in the MTA and the thread receives a proxy to the object. All calls are marshalled between the two threads via the proxy and COM infrastructure. MTA thread creates STA object: The object is created in a special STA called the Host STA and the thread receives a proxy to the object. All alls are marshalled between an MTA thread and the Host STA thread. Exactly what the marshalling entails depends on what type of apartment transitionis being executed, but assuming the object is not in the neutral apartment it always involves at least two thread switches. Regards Richard Blewett - DevelopMentor http://www.dotnetconsult.co.uk/weblog http://www.dotnetconsult.co.uk > Some objects may even be marked as MTA-only, in which case you have to > create them from another MTA thread if you don't want marshalling to get > in the way. thank you again for your quick and good explained answer! so the communication between public appartment and the threads own appartment is called marshalling. as far as i understand is marshalling like a telephone between own appartment and public appartment. the only difference between public and own apparment is that it costs performance to "call" to the other "room". or the other thing you said is that some objects are marked as MTA only and can not talk to the phone to communicate with the private appartment. so you have to create some kind of a dragoman in the public appartment which can speak directly to that object and give answer to the private appartment... is that analogy correct? if yes, here my last question to understand the situation: you said, when i have a thread in the STA which wants to communicate with an object in the MTA (not marked as MTA only!), it has to be marshalled... who is doing that marshalling between the appartments? the compiler, the OS or do i have to do that on my own? are there any windows APIs which i can do the that, if i have to do the marshalling on my own? regards, jazper |
|
|
|
#16 |
|
Guest
Posts: n/a
|
OLE1 was not based on COM, that is it did not follow the COM binary
standards. And more importantly, it did not have a notion of apartments as there where even no threads on 16 bit windows. Willy. "Joakim Karlsson" <jkarlsson@NOSPAMjkarlsson.com> wrote in message news:OwfLCMh%23EHA.3472@TK2MSFTNGP14.phx.gbl... > OLE1 (and IIRC 16-bit OLE2) was around for 16-bit Windows. OLE1 actually > used DDE for it's communication if memory serves me. > > But you are correct, I did take a few liberties in my post. What I wanted > to do was set the stage for why the STAThread and MTAThread are there. > There are much better articles and books if one wants to get in to the > details. > > Regards, > Joakim > > Willy Denoyette [MVP] wrote: >> A few mistakes.... >> There's never been a version of COM for 16 bit windows. So there have >> never been 16 bit applications based on COM. >> >> Willy. |
|
|
|
#17 |
|
Guest
Posts: n/a
|
Richard,
The only thing I know which looks like a 16 bit version of COM is OLE1 and OLE2, but as far as I know these puppies where developed by the Office team and do not follow the COM specifications released back in 1993. The Windows 3.1 and 3.11 OLE2 system component was not apartment/thread (obviously the OS had no threads) aware, CoInitialize did not exists (OleInitialize did). Reasons for me not to consider this as a 16 bit COM. Willy. Note: that the later completely redesigned OLE32 was COM based. "Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in message news:uuRLlNd%23EHA.2540@TK2MSFTNGP09.phx.gbl... > Actually there was a 16 bit version of COM - is was mostly a bit of an > oddity but it did exist (you can dig out various articles from the 90s > that mention it). > > Regards > > Richard Blewett - DevelopMentor > http://ww.dotnetconsult.co.uk/weblog > http://ww.dotnetconsult.co.uk > > A few mistakes.... > There's never been a version of COM for 16 bit windows. So there have > never > been 16 bit applications based on COM. > > Willy. > |
|
|
|
#18 |
|
Guest
Posts: n/a
|
> There is no concept of a "public apartment". Every thread must enter an
apartment when it performs COM work - thats what the call to CoInitialize(Ex) is for. So a thread initializes itself into its own STA or it joins the proces-wide MTA. it was just an analogy to understand the difference. so the communication between the 2 appartment models is called marshalling. who is doing that marshalling between the appartments? the compiler, the OS or do i have to do that on my own? are there any windows APIs which i can do the that, if i have to do the marshalling on my own? BTW: on nearly every post i made i asked for a concrete example... (i mean an example i would face in a real application). is there no concrete example i can see why this all is good for? if not i wonder why this is needed then... please give me 1 example... only one concrete example... please... :-) regards, jazper |
|
|
|
#19 |
|
Guest
Posts: n/a
|
I am sure you are correct, but these kind of details dos not help the
original poster whatsoever. I never stated that apartments were around on 16-bit Windows, actually I said the opposite. Regards, Joakim Willy Denoyette [MVP] wrote: > OLE1 was not based on COM, that is it did not follow the COM binary > standards. And more importantly, it did not have a notion of apartments as > there where even no threads on 16 bit windows. > > Willy. |
|
|
|
#20 |
|
Guest
Posts: n/a
|
OK concrete examples:
If you are writing an application that needs to utilize a legacy VB6 component you need to be aware of apartment issues. If the VB6 component has a chatty interface say using properties (as often VB6 components would as their whole world was in the same STA in general) then if you don't set the calling thread to also be STA based (say by using the STAThread attribute) then you may well notice a performance impac then you try to use the component (I've also seen a performance hit when using classic ADO - which by default is apartment threaded IIRC - from an MTA thread in terms of perfomance as you have to cross the apartment boundary for every field access of every row in a recordset. If you are writing a GUI application that uses ActiveX controls then unless your UI thread is STA based it will fail to work correctly. As far as MTA based components go, it was fairly rare to make a component MTA based as once you had gone to the trouble to make your component threadsafe (which was required for MTA components there was often no hard in also letting the component run in an STA if it had to (there were issues if you issued blocking calls such as WaitForSingleObject in an STA however) so often componants taht could run in the MTA were often marked with a threading model of "Both" so they would be used efficiently by any thread. Who performs the marshalling? In most situations the COM runtime does. At least if the thread that creates an object is the one calling that object then the COM runtime handles the marshalling. The only issue comes when you want to hand a refernence to a COM object to a thread other than the one that created it. In this case the interface pointer must be marshalled manually using either CoMarshalInterThreadInterfaceInStream/CoGetInterfaceAndReleaseStream of the Global Interface Table Regards Richatrd Blewett - DevelopMentor http://www.dotnetconsuolt.co.uk/weblog http://www.dotnetconsuolt.co.uk > There is no concept of a "public apartment". Every thread must enter an apartment when it performs COM work - thats what the call to CoInitialize(Ex) is for. So a thread initializes itself into its own STA or it joins the proces-wide MTA. it was just an analogy to understand the difference. so the communication between the 2 appartment models is called marshalling. who is doing that marshalling between the appartments? the compiler, the OS or do i have to do that on my own? are there any windows APIs which i can do the that, if i have to do the marshalling on my own? BTW: on nearly every post i made i asked for a concrete example... (i mean an example i would face in a real application). is there no concrete example i can see why this all is good for? if not i wonder why this is needed then... please give me 1 example... only one concrete example... please... :-) regards, jazper -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005 [microsoft.public.dotnet.languages.csharp] |
|
![]() |
|
| Thread Tools | |
| Rate This Thread | |
|
|

Main Page 


