Browse Prior Art Database

Handling Shared Objects in Multi-Process Systems

IP.com Disclosure Number: IPCOM000117047D
Original Publication Date: 1995-Dec-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 98K

Publishing Venue

IBM

Related People

Nash, SC: AUTHOR

Abstract

In a multi-process system such as OS/2*, objects conventionally belong to processes. Objects belonging to the same process can communicate simply by sending messages, but objects belonging to different processes cannot send messages directly to one another. Instead, they must use some other means of inter-process communication, which introduces complexity for the programmer and overheads due to process switching.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Handling Shared Objects in Multi-Process Systems

      In a multi-process system such as OS/2*, objects conventionally
belong to processes.  Objects belonging to the same process can
communicate simply by sending messages, but objects belonging to
different processes cannot send messages directly to one another.
Instead, they must use some other means of inter-process
communication, which introduces complexity for the programmer and
overheads due to process switching.

      The disclosed solution introduces two kinds of objects for use
by multiple processes: shared objects without process affinity, and
shared objects with process affinity.

      Shared objects without process affinity can be used from any
process without a process switch.  Their state resides in shared
memory, which is accessible and updatable from all processes.  Their
operations (typically accessing and updating shared memory) are
independent of the process on which their methods execute.  These
objects provide concurrency control to ensure serialised access to
their shared memory state when concurrently executed from multiple
processes (or, in multithreaded systems, from multiple threads within
a process).  When invoking a method of such an object, there is no
need to switch processes.

      Shared objects with process affinity must execute on a
designated process.  However, they can be used from any process, with
any required process switching being performed transparently by the
object as part of method invocation.  The user of the object (message
sender) need not be aware that the receiver object has process
affinity and is performing a process switch as part of method
invocation.  No process switch is performed when the sender of a
message is already running on the receiver's designated process.

      In all cases, the message sender need not be aware of the
characteristics of the message receiver object (unshared of shared,
process affinity), since it is the receiver object's responsibility
to switch processes only when necessary.  This simplifies the design
and programming of the message sender, and ensures a minimum of
process-switching overhead.

      In one example of implementations by Object REXX for OS/2,
shared objects without process affinity reside in named shared memory
and are accessible from any OS/2 process, with Object REXX providing
the necessary concurrency control.  Shared objects with process
affinity are supported using proxy objects, which are shared objects
without process affinity and so can be accessed from any process.
The proxy object represents the shared...