shared memory

[Danny Boulet]

In article <josef.654158001 at peun11> josef at nixpbe.UUCP (Moellers) writes:
>In <566 at gestetner.oz> andrew at gestetner.oz (Andrew Hunt) writes:
>
>>I am having problems with UNIX shared memory system functions
>>(shmget, shmctl, shmop) - our system is SUN O/S 4.0.x.  
>>I am trying to attach some data to a shared memory identifier.
>
>>	assign global_start_address
>>	assign global_size
>
>>	global_shmid = shmget(IPC_PRIVATE,global_size,0777|IPC_CREAT);
>
>>	shmat(global_shmid,global_start_address,SHM_RDONLY);
>
>>The shmget is always successful but the shmat fails.  I have tried 
>>to assign the global_start_address to many different sizes and 
>>addresses.  The addresses I have tried have been from malloc'ed memory,
>>stack space, initialised data space, uninitialised data space....
>>I have experimented with changing permissions and have changed most of
>>the parameters but the only thing that has worked is to set
>
>>	global_start_address = (char *)0;
>
>>which allow the system to find some space for me.
>
>>Does anyone know what areas of memory can be legally attached to 
>>shared memory?
>
>The system will ALLWAYS find space for You. It's YOUR task to tell it
>			     ^^^^^
>where to put it.
>^^^^^
>The address where to put it ("global_start_address") must not result in
>part or all of the shared memory segment overlaying part or all of Your
>allocated virtual address space.
>So:
>	break <= global_start_address < SP - global_size
>Try something like global_start_address = 0x80000000, which, on a 32 bit
>system, should put the shared memory segment in the middle of Your 4GB
>virtual address space.

Here's another suggestion:  in the systems that I have experience with
their SysV shared memory facilities (Convergent Technologies Miniframe,
Pyramid, Sun 3's and 386's running SCO Xenix), the system wouldn't allow
me to place shared memory just anywhere.  There was only a limited part
of the address space in which shared memory could appear.  If you specified
an address outside of this limited range then the shmat call would fail.

Now for my suggestion:  make a call to shmat using the form that allows
the system to pick where the memory will appear.  Once you know where
the system would like to put the memory, change your program to always
ask for it to be placed at that location.  This allows your program
to know in advance where the memory will land although it means that you
have to repeat this experiment when you try to port the code to some other
system.

Now for the catch:  my experience with SCO Xenix (version 2.3) is quite
limited but I did discover that the system would not allow me to specify
where the memory should appear.  It insisted on being able to chose the
location itself.  I wasn't able to find a work around for this (not too
suprising since the manuals listed this as one of the deviations from SVR3).

Note that my experience is with SCO Xenix (not SCO UNIX).  The SCO UNIX
may or may not be more flexible.  One of the problems is that the Intel 80386
MMU only allows sharing of segments that are multiples of 4M in size and
located on 4M boundaries (actually, you can share less than 4M but everything
within any given 4M block is either shared or unshared).  One of the
consequences of this is that any implementation of shared memory on this
architecture needs to keep this in mind.  Since every MMU that you're
every likely to encounter has some alignment requirements and such, you
need to be careful about what assumptions you make if you want your code
to be portable.

If your software really needs to be able to insist on where the memory
lands then you might have a problem (depending on whether your system
allows you to say where it goes).

>
>--
>| Josef Moellers		|	c/o Nixdorf Computer AG	|
>|  USA: mollers.pad at nixdorf.com	|	Abt. PXD-S14		|
>| !USA: mollers.pad at nixdorf.de	|	Heinz-Nixdorf-Ring	|
>| Phone: (+49) 5251 104662	|	D-4790 Paderborn	|