Shared memory and IPC

[John E. Malmberg]

On Fri, 7 Sep 2001, Luke Kenneth Casson Leighton wrote:

> On Fri, Sep 07, 2001 at 05:17:01AM -0500, Peter Samuelson wrote:
> > 
> > [Wez Furlong]
> > > So there is no nice-n-easy syscall then?  Even a non-portable call
> > > would be better than parsing /proc/self/maps.
> > 
> > Don't look at me, I'm no IPC expert!  (So, that out of the way...)
> > 
> now we have a good reason to justify why MS reserves 2gb of the
> physical memory address space in w95...

The main reason is that you can use the sign bit to tell if you are
pointing to system space or not.  Not really a MS specific hack.

Now it may be that they are allocating the COM memory out of that pool.
It should be real easy to tell, just look at the value of the pointers
returned on a real system.

With out the operating system having intimate knowledge of reserving a
address range of virtual memory for all programs by default, it is not
possible to insure that address range will be available to any specific
program.

Some database programs may also be using that space for enhanced caching.
You would only notice that if you tried to build an IPC procedure that
used that datbases RTL, and it produced a failure.

And it may work with one configuration, but change just one shared
library, and everything could be different.

There is basically no specific address range that I am aware of that is
reserved to be used for interprocess communication.

There is a lot of space, so it is likely that an implementation can
get away in most cases, but no real way to insure that there will never
be a conflict for general programming.

So, again, unless the Operating System reserves an address space for IPC
for all programs, you can not come up with a solution that will work in
all cases.

You can probably come up with a solution that will work in *MOST* cases,
but the exceptions are likely to be database programs, and database
programs are high on the list of things that are nice to be IPC enabled.

> 
> the only issue with mmap() without MAP_FIXED is that you
> won't get a real physical address back, you'll get a
> virtual address back.
?
The only thing that matters is that all processes have the memory mapped
to the same virtual address.  Shared memory can be demand paged.  With
an MMAP file, it would be expected that modified memory would be paged
back to the file.

The physical address mapping only matters to IO Drivers.
 
-John
wb8tyw at qsl.network
Personal Opinion Only