Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!techunix.BITNET!devil
From: devil@techunix.BITNET (Gil Tene)
Newsgroups: comp.unix.wizards
Subject: Re: shmat() system call?
Message-ID: <9763@discus.technion.ac.il>
Date: 17 Aug 90 15:44:14 GMT
References: <27@astph.UUCP> <12636@hydra.gatech.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: devil%techunix.bitnet@jade.berkeley.edu (Gil Tene)
Organization: Technion, Israel Inst. Tech., Haifa Israel
Lines: 53

In article <12636@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes:
>in article <27@astph.UUCP>, jeff@astph.UUCP (8592x2) says:
>>
>>
>> Question concerning the shared memory attach call:
>>
>> I am writing a shared memory allocation manager for a multi-user
>> database. This manager will allow several processes to be attached
>> to the same memory segment at the same time. The first process to
>> attach to the shared memory segment will be returned a memory address
>> that points to the shared memory block.
>>
>> I need to know if additional attaches by other processes will be
>> guaranteed to return the same address as that the first process
>> was returned. I am aware that you can request a particular address,
>> but why bother communicating that information between the processes
>> if the same address is returned anyway? I would appreciate any
>> answers or direction to documentation.
>
>I don't see why not. The shmget(2) routine specifies the memory block
>size. All the shmat(2) routine does is return a pointer to the beginning
>of that block (by default). The same block is returned to different
>processes if they use the same shmid returned by shmget(2). Adapted from
>the HP 9000/800 HP-UX Real Time Programmers Manual:
>

To start with : Don't risk it.

shmat() attaches to a shared memory block. Each process on a VIRTUAL
MEMORY system may have this block attached at a different VIRTUAL address.
It IS possible to specify a specific address to be used for the mapping,
but this is risky for two reasons : a) some other application may
be mapping the same address. b) some systems DO NOT ALLOW THIS OPTION.

I have had experience with this kind of problem. My experience on Sun-3
systems running SunOS 4.0.3 is that the shmat() DOES return the same
mapping address in all processes. When moving soem software to an
Hp 900/375 running HP-UX 7.0 some of the design flaw's surfaced :
HP-UX DOES NOT map to the same address, and this software had
shared POINTERS. This was easy to fix, as most pointers can be
replaced with offsets, and workarounds can be done for anything else.

In short : If you want portable sysV shared memory code, don't assume
shmat() returns the same address in all processes. You'll find out
FAST on any system that does not.

Gil.

--
--------------------------------------------------------------------
| Gil Tene                      "Some days it just doesn't pay     |
| devil@techunix.technion.ac.il   to go to sleep in the morning."  |
--------------------------------------------------------------------