TLS and in-proc server (need clarification...)
| Author |
Message |
|
José
#1 / 6
|
 TLS and in-proc server (need clarification...) Hello,
I'm a bit puzzled with the threading aspect in COM DLL.
I have an existing application (set of classes) around
which I want to wrap a COM interface.
The target component must be a COM dll that will be an in-
proc server (OR possibly hosted by a surrogate [eg: the
W2k component services feature]).
The problematic I have is that the existing set of classes
uses the TLS area to store information that must be valid
during the complete object life cycle. In that sense, I
have to guaranty that a given instance of a COM object
will always be handled by the thread that have created the
object (in the "COM server").
On the client side, the thread that created the object
will be the one that will call the methods of this object
(there will be no exchange of objects between client
threads).
To my understanding, for the in-proc server, there is no
problem, I can use either STA, MTA or NA.
In the case the object is hosted by a surrogate, I'm not
clear at all which model is suitable.
Sincerely,
Jos
|
| Sat, 30 Oct 2004 01:48:49 GMT |
|
 |
|
Igor Tandetni
#2 / 6
|
TLS and in-proc server (need clarification...) Based on your description, you want your object to be STA. It does not matter whether it is hosted direcly by the client or by a surrogate. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
Hello,
I'm a bit puzzled with the threading aspect in COM DLL.
I have an existing application (set of classes) around
which I want to wrap a COM interface.
The target component must be a COM dll that will be an in-
proc server (OR possibly hosted by a surrogate [eg: the
W2k component services feature]).
The problematic I have is that the existing set of classes
uses the TLS area to store information that must be valid
during the complete object life cycle. In that sense, I
have to guaranty that a given instance of a COM object
will always be handled by the thread that have created the
object (in the "COM server").
On the client side, the thread that created the object
will be the one that will call the methods of this object
(there will be no exchange of objects between client
threads).
To my understanding, for the in-proc server, there is no
problem, I can use either STA, MTA or NA.
In the case the object is hosted by a surrogate, I'm not
clear at all which model is suitable.
Sincerely,
Jos
|
| Sat, 30 Oct 2004 02:08:44 GMT |
|
|
|
Jose Joy
#3 / 6
|
TLS and in-proc server (need clarification...) I forgot to mention that the processing of some methods may be time consuming (not processor consuming...). In that sense, I do not like the idea of serializing the calls. I would really like to have them processed in parallel. Jos
Quote: > Based on your description, you want your object to be STA. It does not > matter whether it is hosted direcly by the client or by a surrogate. > -- > With best wishes, > Igor Tandetnik > "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken
> Hello,
> I'm a bit puzzled with the threading aspect in COM DLL.
> I have an existing application (set of classes) around
> which I want to wrap a COM interface.
> The target component must be a COM dll that will be an in-
> proc server (OR possibly hosted by a surrogate [eg: the
> W2k component services feature]).
> The problematic I have is that the existing set of classes
> uses the TLS area to store information that must be valid
> during the complete object life cycle. In that sense, I
> have to guaranty that a given instance of a COM object
> will always be handled by the thread that have created the
> object (in the "COM server").
> On the client side, the thread that created the object
> will be the one that will call the methods of this object
> (there will be no exchange of objects between client
> threads).
> To my understanding, for the in-proc server, there is no
> problem, I can use either STA, MTA or NA.
> In the case the object is hosted by a surrogate, I'm not
> clear at all which model is suitable.
> Sincerely,
> Jos
|
| Sat, 30 Oct 2004 02:58:03 GMT |
|
|
|
Igor Tandetni
#4 / 6
|
TLS and in-proc server (need clarification...) That's too bad, because "perfoms processing in parallel" and "uses TLS" properties are incompatible. You can't have both. Unless your object is stateless, in which case the client can spin multiple STA threads and create one instance of the object on each such thread. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
Quote: > I forgot to mention that the processing of some methods may be time > consuming (not processor consuming...). In that sense, I do not like the > idea of serializing the calls. I would really like to have them processed in > parallel. > Jos
> > Based on your description, you want your object to be STA. It does
not
> > matter whether it is hosted direcly by the client or by a surrogate.
> > --
> > With best wishes,
> > Igor Tandetnik
> > "For every complex problem, there is a solution that is simple,
neat,
> > and wrong." H.L. Mencken
> > Hello,
> > I'm a bit puzzled with the threading aspect in COM DLL.
> > I have an existing application (set of classes) around
> > which I want to wrap a COM interface.
> > The target component must be a COM dll that will be an in-
> > proc server (OR possibly hosted by a surrogate [eg: the
> > W2k component services feature]).
> > The problematic I have is that the existing set of classes
> > uses the TLS area to store information that must be valid
> > during the complete object life cycle. In that sense, I
> > have to guaranty that a given instance of a COM object
> > will always be handled by the thread that have created the
> > object (in the "COM server").
> > On the client side, the thread that created the object
> > will be the one that will call the methods of this object
> > (there will be no exchange of objects between client
> > threads).
> > To my understanding, for the in-proc server, there is no
> > problem, I can use either STA, MTA or NA.
> > In the case the object is hosted by a surrogate, I'm not
> > clear at all which model is suitable.
> > Sincerely,
> > Jos
|
| Sat, 30 Oct 2004 03:32:16 GMT |
|
|
|
pinchbec
#5 / 6
|
TLS and in-proc server (need clarification...)
Quote: >The problematic I have is that the existing set of classes
>uses the TLS area to store information that must be valid
>during the complete object life cycle. In that sense, I
In COM a client instance of a component is identified and tracked by the runtime by it's Context ID. From NT4.0 to Win2k SP1 the COM runtime allocated one client context to one thread. So multi-threading programming techniques worked well. However, starting from Win2k SP2 COM is thread pooled. One thread services many client contexts. Contexts are switched when client components call outside of their apartment boundaries. The execution and return from out of apartment calls is handled in a LIFO fashion. This now means that you can not use TLS or multi-threading constructs that
are based on thread identifier because multiple client contexts may run on
the exact same thread. Your TLS is going to get all screwed up. You are
going to experience deadlocked code.
The solution is that you have to rewrite and keep all client instance data
inside an object instance.
cheers.
|
| Sun, 31 Oct 2004 02:35:40 GMT |
|
|
|
José Joy
#6 / 6
|
TLS and in-proc server (need clarification...) Thanks for the clarification. I think that your final comment is the best I have to do.
Jos
Quote:
> >The problematic I have is that the existing set of classes
> >uses the TLS area to store information that must be valid
> >during the complete object life cycle. In that sense, I
> In COM a client instance of a component is identified and tracked by the
> runtime by it's Context ID. From NT4.0 to Win2k SP1 the COM runtime
> allocated one client context to one thread. So multi-threading
programming
> techniques worked well. However, starting from Win2k SP2 COM is thread
> pooled. One thread services many client contexts. Contexts are switched
> when client components call outside of their apartment boundaries. The
> execution and return from out of apartment calls is handled in a LIFO
> fashion.
> This now means that you can not use TLS or multi-threading constructs that
> are based on thread identifier because multiple client contexts may run on
> the exact same thread. Your TLS is going to get all screwed up. You are
> going to experience deadlocked code.
> The solution is that you have to rewrite and keep all client instance data
> inside an object instance.
> cheers.
|
| Mon, 01 Nov 2004 03:48:59 GMT |
|
| |
|
