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. So implementor does not have to
write extra code to synchronize data. More precisely, in case of 'STA'
global data functions like DllGetClassObject() does not get secured,
instead just the class data gets secured. In case of 'Apartment' mode
both global and class data gets secured. Before actually writing code,
I was under the impression that this serialization is limited to a
specific 'instance' of COM class, but in my sample, serialization
occured across all 'instances' COM class. Please confirm if this is
the way the things are supposed to work.
In case of MTA, com does not stop call from reaching the server, and
is up to the implementor of server to take care of protecting data.
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. Without using this compile time
define, is there a way to bring that effect, dynamically at run time.
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 on others.
If you mean "make your BOTH coclasses" then that is what I am was
trying to convey.
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.
CComObjectRootEx<CComMultiThreadModel>,
CComObjectRootEx<CComSingleThreadModel>,
Following sample seems somewhat redundant. This is the sample that I
used for testing. AltFreeClnt.exe is client for AtlFree.exe exposing
two coclasses(CComMultiThreadModel, CComSingleThreadModel).
AltFreeClnt.exe invokes the methods of both coclasses
Client - AtlFmtClnt.exe
----------------
int _tmain(int argc, _TCHAR* argv[])
{
//Launch new instance of AptFree object to call just one method
Td[0] = _beginthreadex(,,&Func1F,,,);//calls AptFree::Method1()
Td[1] = _beginthreadex(,,&Func2F,,,);//calls AptFree::Method2()
Td[2] = _beginthreadex(,,&Func3F,,,);//calls AptFree::Method3()
//Launch new instance of StaObject object to call just one method
Td[3] = _beginthreadex(,,&Func1S,,,);//calls StaObject::Method1()
Td[4] = _beginthreadex(,,&Func2S,,,);//calls StaObject::Method2()
Td[5] = _beginthreadex(,,&Func3S,,,);//calls StaObject::Method3()
//wait for threads
WaitForMultipleObjects(6,(HANDLE*)Td, 1, INFINITE) ;
//1) When _ATL_APARTMENT_THREADED is set on server side
// all 6 methods get executed sequentially.
//2) When _ATL_FREE_THREADED is set on server side
// all 6 methods run parallel.
}
Server - AtlFree.exe
---------------
<stdafx.h>
#define _ATL_FREE_THREADED //makes call paralell
//#define _ATL_APARTMENT_THREADED //Makes every call sequential
<AtlFree.idl>
coclass AptFree
{
[default] interface IAptFree;
};
coclass StaObject
{
[default] interface IStaObject;
};
<AptFree.h>
class ATL_NO_VTABLE CAptFree :
public CComObjectRootEx<CComMultiThreadModel>,
{
STDMETHOD(Method1)(LONG code);
STDMETHOD(Method2)(LONG code);
STDMETHOD(Method3)(LONG code);
};
<StaObject.h>
class ATL_NO_VTABLE CStaObject :
public CComObjectRootEx<CComSingleThreadModel>,
{
STDMETHOD(Method1)(LONG code);
STDMETHOD(Method2)(LONG code);
STDMETHOD(Method3)(LONG code);
};
Regards,
Ramesh
On Aug 8, 10:22 pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
asnowf...@gmail.com wrote:
Till now I was changing the setting at CoClass level. It seems CoClass
hardly controls its own Threading model, instead it is controlled by
process level #define.
That's just the way ATL wizard arranges things, because that's good
enough for an overwhelming majority of applications. But, if you have
some special requirements, feel free not to use wizard-generated code
and do everything yourself. It is entirely possible to register one
coclass from an STA thread and another from an MTA thread (though I
don't quite see why you would want to do that).
Today, to confirm this, I wrote a sample, with
one STA and MTA coclass in the same binary.
What do you mean, one STA and one MTA coclass? What do you believe makes
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 on others.
You seem to labor under some fundamental misconceptions of how threading
models work.
--
With best wishes,
Igor Tandetnik
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