TLS and in-proc server (need clarification...) 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 6 post ] 

 Relevant Pages 

1. Basic questions about CLSCTX enum, inproc and out-of-proc servers

2. Starting an inproc server as a local server using a DLL Surrogate

3. thread local storage (tls), Compiler Implementation for TLS

4. Converting In-Proc Server to out-Proce Server?

5. registering ATL inproc server

6. InProc Server (Marshalling problem)

7. problem with CreateThread in the InProc server.

8. Inproc Server loading Java HotSpot DLL

9. Registering in the ROT an ActiveX object implemented in an inproc server

10. Remote Debugging An Inproc Server

11. * export enums from ATL inproc server to clients

12. Quesion on Loadlibrary in an Inproc Server...

 

 
Powered by phpBB® Forum Software