Re: Portable Class For Shared Memory
On Oct 1, 10:41 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
Okay. I was thinking that you were allowing each process to create a chunk
of its own shared memory that it subsequently registers with a
master/shared
memory manager or something. So, a process can't 'bind' to a chunk of your
shared memory; request/allocate a block; use that block and release/free
_before_ a call to 'unbind' from has been made?
No.
It's the simplest use of shared memory: a huge (1MB) block of memory
that is visible by any process that wants to see it. I only wanted a C+
+ class because my system has to run on many OS's, and shared memory,
along with synchronization primitives and a device driver, represent
about 2% of of my system that is non-portable. I know it is not
possible to make the .cpp file for a class that allows access to
shared memory strictly portable, so I wanted a portable interface at
least.
What if that process was in the middle of mutating something when it
crashed? Are you keeping CRC's or something? What about the subsequent
memory leak that will not allow the shared memory to be unmapped because
the
refcount will never drop to 1?
I use system-wide mutexes and semaphores for access control, etc.
Since this is shared memory across process boundaries, the reference
counts are maintained in the kernel, so if a process dies, the kernel-
mode process manager guarantees that all bindings by that process to
kernel-mode things are release, decrementing reference counts
accordingly.
However, the shared memory is broken into 8KB structs that are marked
as being used or not, so if a process exits abnormally, thought the
entire pool is unmappable by OS, any structs that were not freed by
destructors referencing the structs will be lost. I could find ways
around this, but I prefer not. ;)
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]