Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!usc!rutgers!mephisto!prism!gt0178a
From: gt0178a@prism.gatech.EDU (BURNS,JIM)
Newsgroups: comp.unix.wizards
Subject: Re: shmat() system call?
Message-ID: <12636@hydra.gatech.EDU>
Date: 16 Aug 90 05:41:44 GMT
References: <27@astph.UUCP>
Organization: Georgia Institute of Technology
Lines: 84

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:

On shmget(2):

"If your communication application consists of related processes, you
should call shmget(2) with the key parameter set to IPC_PRIVATE in the
following way:

   myshmid = shmget (IPC_PRIVATE, 4096, 0600);

"This call to shmget(2) returns a unique shared memory identifier (shmid),
which is saved in the variable myshmid, for the newly created shared
memory segment. The size of the segment is 4096 bytes and its access
permissions are read and write permission for the owner. This call to
shmget(2) should appear in your program sometime before the fork()
statement so that the child processes in your communication application
will inherit myshmid.

"If your communication application consists of unrelated processes, you
should call shmget(2) with the key parameter set to the return value of
the ftok() subroutine [or just use an ascii representation of a 4
character string that you know will be unique. - JB ] [...] As an example,
all unrelated processes in a communication application can call shmget(2)
in the following [altered - JB ] way:"

   myshmid = shmget (0x50485331, 4096, IPC_CREAT|600);

to use a key of "PHS1".

On shmat(2):

"Once a process has a valid shmid, it usually wants to attach, perhaps to
lock, to read and/or to write to, and then to detach the shared memory
segment. [...]

"A process must invoke the shmat() system call to attach a shared memory
segment to the data space of the process. The man page for shmop(2) lists
three parameters for shmat(): shmid, shmaddr, and shmflg.

"The first parameter, shmid, must be a valid shared memory identifier as
explained in the previous section.

"The second parameter, shmaddr, is the attach address of the shmid
parameter. Parameter shmaddr should be 0 in almost all cases. Only at
certain times and only in certain implementations of HP-UX can shmaddr be
other than 0. If a previous shmat() has not been called on the shmid; that
is, if the shared memory segment has not already been attached, then the
only correct value for shmaddr is 0. If, however, some process has already
called shmat() on the specified shmid, then the shmaddr can be 0 or some
other implementation - dependent value. [...] [As it turns out, non-zero
parameters aren't supported at all on the model 800 architechture - only
the 300. -JB ]

"The third parameter of shmat(), shmflg, is used only to further restrict
the owner's access permissions to the shared memory segment. [...]"

Hope this answers your question.
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a@prism.gatech.edu