Sharing Global Data 
Author Message
 Sharing Global Data

You have an in-proc server in a DLL. Each process has a copy of this DLL
loaded, and each copy has its own global data. While all instances or your
object created in the same process share the same data, instances in
different processes have independent copies of global data.

To work around it, you need to either make your COM server out-of-proc, or
perform some kind of interprocess communication to syncronize this data. For
simple data structures, see KB Article Q125677 "HOWTO: Share Data Between
Different Mappings of a DLL".
--
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 COM DLL written in ATL, with the threading model specified as
> Both.  Various instances of the COM object (call it Object/IObject)
> are meant to be created by different apps at the same time, but each
> instance is meant to share the same settings data (though clients are
> not directly accessing it).  To this end, I simply made the data
> global (I stuck it all in a settings.cpp file).
> When I create multiple instances of my object from VB, the COM object
> behaves as intended -- They all share the same global data.  However,
> when I create instances from an MFC C++ object, I get multiple copies
> of the global data (so that if I change it in one instance, the other
> instance doesn't see it).  I am creating instances in C++ using smart
> pointers, as such:

> #import "object.dll" no_namespace       // in stdafx.h

> IObjectPtr objPtr;
> CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
> objPtr.CreateInstance(__uuidof(Object));

> I am unable to find the cause of this behavior -- Is it an error being
> made on the COM server side, or on the client side?  I have attempted
> to make my COM DLL a singleton by putting
> DECLARE_CLASSFACTORY_SINGLETON in my .h file, but that didn't seem to
> help matters any (and I don't think is the correct solution anyways).

> I would be appreciative for any help.  Please let me know if there is
> any information I ommitted that is necessary for understanding the
> problem.  Also, if there is a more appropriate forum for this
> question, please redirect me there.

> Thanks,

> Matt Pauker
> mpauker(at)stanford.edu



Mon, 24 May 2004 01:20:45 GMT  
 Sharing Global Data
You cannot use a critical section, but you can use a named mutex and/or
event. Instead of putting it in a shared section, each DLL instance just
creates a mutex with the same name. OS makes sure they end up with the
handle to the same object.

Registry access is thread-safe. Of course, if two instances write two
different strings to the same value at about the same time, there's no
telling which of the strings finally gets stored. But it's either one or the
other, and Windows won't crash.
--
With best wishes,
    Igor Tandetnik

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


Quote:
> Thanks for the response.  The easiest solution for me is probably to make
> my COM server an out-of-proc EXE -- I have some dynamic char ** arrays
> that I need to store, and from what I understand from that KB article (and
> other pages on the subject), I can only share statically allocated char[]
> arrays with that method.  Also, using that solution would seem to make
> locking very difficult -- Presumably you could not include an ATL
> CriticalSection in the shared section (since it does not have a 'shallow'
> copy constructor), and there's no guarantee that a simple boolean
> variable is atomic.  (Is this all correct?)
> ...which leads me to another question: in a regular in-proc DLL COM
> server, if all the instances of the DLL read/write things into the
> registry (and obviously write into the same registry section), how do you
> prevent the various instances from accessing the registry at the same
> time?  Do CRegKey.Open()/CRegKey.Create() perform locking?

> Thanks,

> Matt Pauker
> mpauker(at)stanford.edu


> > You have an in-proc server in a DLL. Each process has a copy of this DLL
> > loaded, and each copy has its own global data. While all instances or
your
> > object created in the same process share the same data, instances in
> > different processes have independent copies of global data.

> > To work around it, you need to either make your COM server out-of-proc,
or
> > perform some kind of interprocess communication to syncronize this data.
For
> > simple data structures, see KB Article Q125677 "HOWTO: Share Data
Between
> > Different Mappings of a DLL".
> > --
> > With best wishes,
> >     Igor Tandetnik

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



> > > Hi,

> > > I have a COM DLL written in ATL, with the threading model specified as
> > > Both.  Various instances of the COM object (call it Object/IObject)
> > > are meant to be created by different apps at the same time, but each
> > > instance is meant to share the same settings data (though clients are
> > > not directly accessing it).  To this end, I simply made the data
> > > global (I stuck it all in a settings.cpp file).
> > > When I create multiple instances of my object from VB, the COM object
> > > behaves as intended -- They all share the same global data.  However,
> > > when I create instances from an MFC C++ object, I get multiple copies
> > > of the global data (so that if I change it in one instance, the other
> > > instance doesn't see it).  I am creating instances in C++ using smart
> > > pointers, as such:

> > > #import "object.dll" no_namespace       // in stdafx.h

> > > IObjectPtr objPtr;
> > > CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
> > > objPtr.CreateInstance(__uuidof(Object));

> > > I am unable to find the cause of this behavior -- Is it an error being
> > > made on the COM server side, or on the client side?  I have attempted
> > > to make my COM DLL a singleton by putting
> > > DECLARE_CLASSFACTORY_SINGLETON in my .h file, but that didn't seem to
> > > help matters any (and I don't think is the correct solution anyways).

> > > I would be appreciative for any help.  Please let me know if there is
> > > any information I ommitted that is necessary for understanding the
> > > problem.  Also, if there is a more appropriate forum for this
> > > question, please redirect me there.

> > > Thanks,

> > > Matt Pauker
> > > mpauker(at)stanford.edu



Mon, 24 May 2004 04:39:13 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Sharing global data using #pragma data_seg directive

2. Uninitialized global data (was Re: Global variables)

3. DLL with shared data/class not sharing...

4. Common areas/common data/data sharing

5. How can I use/share global variables and objects in an ASP.NET application

6. Global Variables in Shared Objects

7. global variable shared by several files

8. LNK2005 - Sharing global variables

9. Shared global variables

10. Shared global variables

11. Sharing a global variable in a DLL

12. too much global data defined in file

 

 
Powered by phpBB® Forum Software