Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!ucselx!bionet!agate!ucbvax!hplabs!hpda!hpcupt1!jonb
From: jonb@hpcupt1.cup.hp.com (Jon Bayh)
Newsgroups: comp.sys.hp
Subject: Re: shared memory on fixed address on 9000/825
Message-ID: <67870008@hpcupt1.cup.hp.com>
Date: 30 Mar 91 00:03:56 GMT
References: <1991Mar26.190339.13805@rusmv1.rus.uni-stuttgart.de>
Organization: Hewlett Packard, Cupertino
Lines: 32


	There are two responses to this string, one from Mike Stroyan and
one from Dave Decot.  Mike's is correct in every detail;  Dave's
is not entirely right.

	All SHARED items in the S[78]00 system use the same virtual address,
both space ID and offset, and use protection IDs to prevent unauthorized access
to the virtual address space.  This includes shared text, shared memory, and
(in 8.0) shared libraries.  For user stack, user data, and kernel stack,
the virtual addresses are different for each process.  Often this is
accomplished by using a different space ID for each process, but retaining
the same offset.  As Mike said, the reason this mapping is used is because
a virtual cache is used, rather than a physical cache.  The primary reason
that a virtual cache is used is to provide faster access to the cache---
both the cache lookup and the virtual translation can go on in parallel.

	Since the virtual address mapping is always at a fixed address for
all processes that access a given shared memory segment, you can use
pointers into the virtual segment without worrying about addr+offset
computations.  That's in stark contrast to a machine that allows you
to assign the segment to an arbitrary address; in that case, all programs
using the shared memory would have to agree on an attach point if they
want to share pointers to data.  The one thing you do have to watch out
for with the HPPA mapping, is that each time the shared memory segment is
created (as opposed to being attached), a different address may be used than
was used the last time.  So you can't, for instance, run a program, save
the data and pointers to a file, restart the program, attach a new
shared memory segment, and use the old data and pointers.  Addr+offset based
programs are always more portable, even though they may be slower.

			Jon Bayh
			jonb@hpda.cup.hp.com