Confused regarding apartments, when COM objects are forced by COM to be created and when shared 
Author Message
 Confused regarding apartments, when COM objects are forced by COM to be created and when shared

Hi,

I have a big confusion regarding apartments, when COM objects are forced by
COM to be created and when they are reused by clients and how to find out at
runtime and/or at compile time what to expect in this regard. An example
might show you why my concern.

I have one EXE that is linked with a DLL, but this DLL is also a COM server
so other DLLS or EXEs may create objects from it.  Suppose as simple
exercise that this "shared" DLL kept a counter and exposed an Increment()
and GetValue() methods.  Now let's call the first EXE client A, and the
other client B.  How do I know B reutilizes the same instance of the COM
server?  Say they are all in the same process - otherwise I think a new
instance should be created or should it??? (this is where I get confused) -
when B needs the COM server and asks for a pointer to one of its interfaces
(say IUnknown) then its reference count could increase and then the object
would be shared. From here on, its state would be shared, so that if A calls
Increment() twice and B Increment() twice(), and then B calls GetValue(), B
would be surprised to see that the value is 2 more than he would have
expected.

This is what I need to figure out. When are COM objects shared and when are
they not shared. Is it the same to solicit an IUnknown interface to them as
to CoCreateInstance?  Can one determine by looking (if possible) at the
value of the reference count if the object is currently being used by
someone else?

I am close, but just a bit confused. Some light could make a lot of
difference.

Thanks again!!

Best regards,
Juan Dent



Sat, 08 Jan 2005 08:42:40 GMT  
 Confused regarding apartments, when COM objects are forced by COM to be created and when shared
When two separate EXEs use a DLL server, the DLL gets mapped
independently into each process' address space. The two DLL mappings do
not interact in any way, they are completely separate, no sharing
occurs.

Suppose you have two parts of the same process each create an object
from the DLL. Well, then two objects get created, and each part gets its
own instance. Of course you can make those objects talk to each other
somehow behind the scenes, or you can make them completely independent,
it's up to you. You should realise that a server can support multiple
objects of the same or different kinds at the same time, and those
objects may or may not interact with each other.

Sharing may occur if the client creates an object and then passes its
interface pointer to some other part of the program. Then those two
should not really be surprised that the object is shared - they have
explicitly asked for it.

The only exception to this pretty picture is a singleton object. Those
should only be implemented in an out-of-proc (EXE) server. In this case
every client requesting a new object actually gets a reference to the
same single object (hence the name "singleton"), so the object is
shared. In this case the author probably had a compelling reason to make
the object a singleton, and you actually want it to be shared.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Quote:
> Hi,

> I have a big confusion regarding apartments, when COM objects are
forced by
> COM to be created and when they are reused by clients and how to find
out at
> runtime and/or at compile time what to expect in this regard. An
example
> might show you why my concern.

> I have one EXE that is linked with a DLL, but this DLL is also a COM
server
> so other DLLS or EXEs may create objects from it.  Suppose as simple
> exercise that this "shared" DLL kept a counter and exposed an
Increment()
> and GetValue() methods.  Now let's call the first EXE client A, and
the
> other client B.  How do I know B reutilizes the same instance of the
COM
> server?  Say they are all in the same process - otherwise I think a
new
> instance should be created or should it??? (this is where I get
confused) -
> when B needs the COM server and asks for a pointer to one of its
interfaces
> (say IUnknown) then its reference count could increase and then the
object
> would be shared. From here on, its state would be shared, so that if A
calls
> Increment() twice and B Increment() twice(), and then B calls
GetValue(), B
> would be surprised to see that the value is 2 more than he would have
> expected.

> This is what I need to figure out. When are COM objects shared and
when are
> they not shared. Is it the same to solicit an IUnknown interface to
them as
> to CoCreateInstance?  Can one determine by looking (if possible) at
the
> value of the reference count if the object is currently being used by
> someone else?

> I am close, but just a bit confused. Some light could make a lot of
> difference.

> Thanks again!!

> Best regards,
> Juan Dent



Sun, 09 Jan 2005 07:29:50 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. confused by COM apartments and threading...

2. Creating COM objects from COM objects

3. Create instance of an com object inside a the Com server

4. Using apartment-threaded VB COM objects from multithread

5. Who's apartment am I in ?

6. I have it kinda but I am really confused.PLease HElp

7. Return a pointer to a nested COM object from a COM object method

8. Invoking COM object from COM object

9. passing COM object pointers to another COM object in ATL

10. COM Object returning COM Object Reference

11. COM object in a COM object

12. Passing COM objects as parameters to other COM objects

 

 
Powered by phpBB® Forum Software