Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.c++
Subject: Re: Objects and Shared Memory
Message-ID: <10153@socslgw.csl.sony.JUNET>
Date: 11 Apr 89 05:21:17 GMT
References: <5462@cbnews.ATT.COM>
Sender: news@csl.sony.JUNET
Reply-To: diamond@diamond. (Norman Diamond)
Organization: /usr/lib/news/organization
Lines: 27

In article <5462@cbnews.ATT.COM> trm@cbnews.ATT.COM (Tom R. Mueller) writes:

>Does anyone know of solutions for the problems associated with
>C++ objects and shared memory in multiple Unix(r) processes.

>... assuming that it isn't
>possible to cause the shared memory to be mapped to the same virtual
>address in every process, there are some more problems.

>Shared objects cannot have ordinary pointers inside them.
>Shared objects cannot have virtual member functions because they are
>implemented with pointers to functions.

These problems existed in older programming languages and in assembler
too, and even before virtual memory.  The necessary solution is the
same.  If some block of memory (or object) has different addresses for
access by different processors (or processes), then pointers within
the block cannot be absolute (whether real or virtual addresses).
They must be offsets of some sort, and the absolute addresses must be
computed by the code doing the access.  Each offset might be relative
to the beginning of the block (e.g. "23 bytes past where you think
the object begins") or self-relative (e.g. "152 bytes before me").

Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-inventing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?