Re: MTA, STA show no change in concurency
What do you believe makes a coclass STA or MTA, precisely?
My understanding is in case of STA, com uses a window to serialize the
message calls coming into STA object.
I didn't mean to ask how COM implements STA or MTA - I meant how, in
your opinion, COM determines whether a particular coclass is STA or MTA.
You seem to believe there's some kind of a compile-time marker.
your main thread enter STA or MTA based on a random number generator,
I guess you are talking about the main thread on server side. On the
server side, #idefine( _ATL_FREE_, _ATL_APARTMENT_THR) are controlling
whether it is going to be STA or MTA.
Only if you rely on ATL code. You can override InitializeCom in your
module class, and initialize COM any way you want. ATL lets you
customize pretty much anything.
a coclass STA or MTA, precisely? You can, if you are so inclined,
have your main thread enter STA or MTA based on a random number
generator, which would make your coclasses STA on some runs and MTA
If you mean "make your BOTH coclasses" then that is what I am was
trying to convey.
You can create one thread that enters STA, and have it call
CoRegisterCoClass for one coclass (don't forget to run a message pump on
that thread). You can further create another thread that enters MTA, and
have it call CoRegisterCoClass for another coclass (that thread can go
to sleep right away, but it must not terminate). Before you ask, there
is no support in ATL for such an unconventional setup, you will have to
code it yourself.
You seem to labor under some fundamental misconceptions of how
threading models work.
May be I am attaching too much weight to following template params,
and thinking these template params are 'soley' responsible for
controlling whether it is STA or MTA. It seems these templates are
part of STA and MTA scheme but do not actaully 'decide' the mode. And
the power to decided STA or MTA is with #idefine( _ATL_FREE_,
_ATL_APARTMENT_THR). Let me know if I am wrong in this regard.
These parameters are a bit of a misnomer. They only control how
thread-safe the object is (not thread-safe with CComSingleThreadModel,
thread-safe with CComMultiThreadModel), but not its threading model as
known to COM. Now, the two are usually in sync: if you intend the object
to live in STA, then there's no point in making it thread-safe, so you
would use CComSingleThreadModel (and similarly for
CComMultiThreadModel). However, you can safely, though somewhat
wastefully, make the object more thread-safe than strictly necessary,
and use CComMultiThreadModel for an STA object. Naturally, you'd better
not go the other way (less thread-safety where more is required), or
you'll introduce race conditions into your server.
With best wishes,
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925