[comp.object] Question on sharing C++ objects between processes

jane@gcm (Jane Kusuma) (12/01/89)

Systems: Sun3, Sun4 / SunOS 4.0.3
Compilers: Sun's C++ (we're still waiting for 1st customer ship)
	   and GNU's g++ (which we have)

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.  In particular,

	(1) is this possible? if so, how?
	(2) can systemV shared memory (shm) be used?
	    is it appropriate? are C++ and shm compatible?
	(3) are light weight processes (lwp) a better alternative?
	(4) other than shm and lwp, are there any other mechanisms
	    available for sharing objects?

Please email responses.  If there's sufficient interest, I'll
summarize and post responses. Thanks in advance.


Jane Kusuma
Greenwich Capital Markets
Greenwich, CT
uunet!gcm!jane

shap@delrey.sgi.com (Jonathan Shapiro) (12/02/89)

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.