In article <11**********************@u32g2000prd.googlegroups .com>,
llothar <ll*****@web.dewrote:
>Sorry i mean of course base address not base directory.
>On most systems you can't map virtual address to the same address
range as in another process - this will not work realiable. Thats why
you need to do all pointer operations in the heap code relative to the
base adresse which you get when you map in the shared memory.
[OT]
I don't know about Windows, but Unix systems (POSIX, including
MacOS), you can use mmap(), the first parameter to which is the
virtual address in the current process that you wish the memory to
(if you specify MAP_FIXED.) Since mmap() is system specific, one
usually knows enough about the standard memory layout to be able to
choose addresses that will not conflict with other mappings. This
is the same semantics as shmat() with a non-NULL address.
>For the
client side of the library all this is invisible, you just need to
pass an additional parameter to malloc/realloc/free and it will be
slower due to the interprocess mutex.
>I thought something like this is a common in the C world.
The memory so allocated cannot be used to store pointers that are
meaningful to all shared address spaces. In order to communicate the
location of the allocated objects between processes, you would have to
have the C code find the offset of the allocated object relative to the
beginning of the shared heap -- but in C, taking pointer differences
between different C objects is undefined behaviour. The implementation
would therefore not only need to provide malloc() and free()
equivilents in the heap: it would also need to provide a call that
returned a heap-relative offset given a pointer and a heap identifier,
and another call that converted a heap-relative offset and a heap
identifier into a local pointer.
Things are so much easier when you just map into the same virtual
address spaces using POSIX semantics -- changes to the shared segment
are automatically reflected in all attachments, without anything
equivilent to "shared memory flush" needed to update caches. If the
system is multiprocessor (or multi-core) but -not- cache-coherent
between the processors (or cores), it isn't clear to me that the system
would meet the POSIX semantic requirements.
But you still have the same difficulty about C having essentially no
atomic operations, so your program pretty much has to add in reliance
upon synchronization primitives -- and if this hypothetical
malloc-in-a-heap library does not want to require dependancy upon any
particular OS's synchronization primitives, then the library
is effectively going to have to provide synchronization primitives
itself.
Clearly effective operations with such a library isn't as simple as
just providing an additional parameter to *malloc() and kin.
Anyhow, the trials and tribulations of shared memory are not
considered appropriate topics for comp.lang.c, since proper operation
of shared memory inherently relies upon system operations
which C knows nothing about (and does not want to know anything
about, because they are not portable to a number of the systems
that C is expected to be able to run on.)
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
