Xref: utzoo comp.object:572 comp.lang.c++:5764 gnu.g++:543
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!lll-winken!arisia!sgi!shinobu!odin!delrey!shap
From: shap@delrey.sgi.com (Jonathan Shapiro)
Newsgroups: comp.object,comp.lang.c++,gnu.g++
Subject: Re: Question on sharing C++ objects between processes
Message-ID: <1717@odin.SGI.COM>
Date: 1 Dec 89 17:44:45 GMT
References: <734@rust>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 40

In article <734@rust> jane@gcm (Jane Kusuma) writes:

>I`m pretty new to the object-oriented / C++ environment and would
>appreciate advice from those more experienced regarding the sharing
>of C++ objects BETWEEN processes...

>	(2) can systemV shared memory (shm) be used?
>	    is it appropriate? are C++ and shm compatible?

Yes and no.  The problem lies partly in the current implementation of
C++ and partly in the implementation of shared memory.

First, shared memory admits of the possibility of multiple threads of
control accessing an object at the same time.  This means that all
operations on the object need to be appropriately semaphored in such a
way as to guarantee that everyone gets a consistent view.

Three basic techniques suggest themselves:

   1. Insert lock() and unlock() members, and use them appropriately.

   2. Have each member function automatically check a semaphore, and
      don't expose any data members as public or protected.  The
      latter restriction is basically to ensure the former, though in
      my opinion it is stylistically preferable because it simplifies
      changing the code.

   3. Implement a smart "pointer to foo" class that locks the real
      item and hands you back a temporary which is another
      pseudo-pointer that unlocks it when it goes out of scope.

A more difficult problem is that, at least as of cfront 2.00 06/30/89,
the 'volatile' keyword isn't supported, so you may have trouble with
getting the boundary conditions right.  Here at SGI we have
(partially) implemented volatile for just this reason.

Hope that helps.

Jonathan S. Shapiro
Silicon Graphics, Inc.


Brought to you by Super Global Mega Corp .com