Re: Application design for shared data repository programmed in VC on Win32 by M
M
Mon Sep 25 12:55:02 CDT 2006
Thanks Carl,my responses are inline
> A couple of suggestions -
>
> First, you can simply created a shared data segment in the DLL. I wouldn't
> recommend this approach as you have to deal in the minutae of PE executable
> memory layout, and there are potential issues that can make your shared
> segement unreachable from some processes.
Yup i wont like to do this low level hack either , its too gory :)
>
> The more flexible technique is to use a memory mapped file to store your
> shared memory. Note, however, that the address of your shared segment is
> not guaranteed to be the same in all processes - you need to use
> window-relative addresses for any "pointers" in your shared structure, and
> ensure that the necessary offsets are applied/removed when manipulating
> these structures.
Will look into this option as well
>
> Since you want access from multiple processes, you need to use cross-process
> synchronization techniques, such as a Mutex for synchronization. A
> CriticalSection can only synchronize access from within a single process.
>
> Given all of the complications with maintaining a shared memory structure,
> you should seriously consider a different design unless your performance
> requirements demand this level of complexity. Most likely they don't. In
> the vast majority of cases, having a single process that manages the shared
> data and communicates through named pipes, sockets, or some other IPC
> mechanism is a cleaner, easier and more maintainable solution.
unfortunately performance requirements do demand this level of
complexity .
However i would also test under different designs like separate process
for managing data store that talks to its clients through some IPC
mechanism
Also any futher suggestion for implementig this as a windows DLL ,
things to guard against , any caveats etc
Carl Daniel [VC++ MVP] wrote:
> "M Taha Masood" <m.tahamasood@gmail.com> wrote in message
> news:1158785114.909006.98810@i42g2000cwa.googlegroups.com...
> > Hello folks,
> >
> > This might be slightly offtopic but not very much so ,since the
> > development is to be done in VC for Win32 environment.
> >
> > I have a requirement whereby there is an in-memory data repository
> > which should be housed in a certain binary module .
> >
> > The access to this in-memory data repository is only through an API
> > exposed by the same binary module.The operations allowable are the
> > creation of new record , deletion of record , update of record, and
> > record search.
> >
> > Moreoever this binary module should provide this API to any application
> > on the same machine and simultaneous access ( protected by some
> > synchronization primitive for data integrity ofcourse ) is also
> > allowable.
> >
> > Now i have a couple of ideas on how to implement this on Win32 ,but
> > would also like to hear about any advice or suggestions that you might
> > have.
> >
> > One of the ideas i am thinking of is along these lines. The binary in
> > which the data repository is housed ,should be a DLL , with exported
> > functions that provide the API for data access.
> >
> > Any application which wants to use the data repository ,would load the
> > DLL in its address space. There should be exactly one copy of the data
> > ( let us say for the sake of discussion for the time being , in a
> > statically allocated array of structures ) for as many applications
> > that have loaded the DLL. The data structure would be a global in the
> > dll.
> >
> > -The memory is typically owned by the any process that loads the dll ,
> > so how do we make it sure that this data structure has memory which is
> > common to as many processes that have loaded the DLL.
> >
> > How does this type of design sound , i would really appreciate any
> > comments and suggestions on this. Or any related best practices.
>
> A couple of suggestions -
>
> First, you can simply created a shared data segment in the DLL. I wouldn't
> recommend this approach as you have to deal in the minutae of PE executable
> memory layout, and there are potential issues that can make your shared
> segement unreachable from some processes.
>
> The more flexible technique is to use a memory mapped file to store your
> shared memory. Note, however, that the address of your shared segment is
> not guaranteed to be the same in all processes - you need to use
> window-relative addresses for any "pointers" in your shared structure, and
> ensure that the necessary offsets are applied/removed when manipulating
> these structures.
>
> Since you want access from multiple processes, you need to use cross-process
> synchronization techniques, such as a Mutex for synchronization. A
> CriticalSection can only synchronize access from within a single process.
>
> Given all of the complications with maintaining a shared memory structure,
> you should seriously consider a different design unless your performance
> requirements demand this level of complexity. Most likely they don't. In
> the vast majority of cases, having a single process that manages the shared
> data and communicates through named pipes, sockets, or some other IPC
> mechanism is a cleaner, easier and more maintainable solution.
>
> -cd