Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!dptg!lzga!bogatko
From: bogatko@lzga.ATT.COM (George Bogatko)
Newsgroups: comp.unix.wizards
Subject: Re: shmat() system call?
Summary: yes and no
Keywords: shmat()  systemV
Message-ID: <2010@lzga.ATT.COM>
Date: 16 Aug 90 12:59:14 GMT
References: <27@astph.UUCP>
Organization: AT&T BL Middletown/Lincroft NJ USA
Lines: 65

In article <27@astph.UUCP>, jeff@astph.UUCP (8592x2) writes:

> The first process to attach the shared memory segment will be returned
> a memory address that points to the shared memory block. 

Not quite.  What you get is an address that is MAPPED into your data-space,
not the physical location of the segment.  A minor point, but one that
should be understood.

> 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.

Not guaranteed, but if the attach is the *VERY FIRST THING* you do
in your client process, then the chances are high that the segment will
be mapped to the same number.  If you do other attaches to other
shared memory segments before the one in question, then the number
will be different.

It doesn't seem to matter (on 3B's at least) if you malloc first, or
have buffers either in data, bss, or stack.  The number that is
returned apparently is a base reserved for shared memory
attachments.  On 3B's, that number starts at 0xc1000000.
I tried an experiment, and saw that the first attach occured at 0xc1000000,
and the second occured at 0xc1020000 even though the segments were
1000 bytes each.  The box has a mind of it's own.

(On a 386, the attaches occured at 0x80400000, and 0x80800000).

> 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?

All the foregoing does not *guarantee* anything.  It is what *seems* to
happen on two particular boxes, given certain circumstances.

If you feel lucky, go ahead and assume that if you do it right and
consistantly, you will get the same number.  If you don't feel lucky,
the you have three options.

1.  Double indirected pointers, or array offset.
    Double indirected pointers is real nasty stuff to do and makes for
    real hard to read code, especially when casting is involved.  Use
    macros.  If you can afford array offset, it will be easier
    to maintain.  With the modern optimizers available nowadays, the
    savings obtained by pointer manipulation as opposed to array-offset
    may not be sufficient to justify the added maintainance difficulty.

2.  Put the location of the shared memory attachment returned from
    the initial shmat call somewhere generally available, and then have
    the clients use that number for the attach.  One suggestion seen on
    the net was to reserve the first [sizeof(char *)] at the front
    of the shared memory segment, and then do two attaches.  One to
    get that number, and the second (after a detach) to re-attach
    to the new number.  The difficulty here is that you still have
    to be careful when you do the second attach.  i.e before or after other
    attaches.  Experiment a lot with this one.

3.  Use the same hard-coded number for all attaches.  This is the simplest,
    least portable, and most offensive way of doing it.  Unfortunately, it
    is the one I've seen most often used.  Yuk.

Hope this helps

GB