Browse Prior Art Database

Improved Communication Between Multiple Processes

IP.com Disclosure Number: IPCOM000118865D
Original Publication Date: 1997-Aug-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Related People

Trotter, M: AUTHOR

Abstract

There are many occasions when multiple processes on a given machine want to communicate with each other and with processes on other machines. This can result in proliferation of process to process communication links such as sockets or pipes. The techniques for using these are well described and work well for communication between individual pairs. Unfortunately, they do not scale well and can lead to an explosion of required resources. The disclosed technique permits control of such growth by a simple protocol using shared memory and 'semaphores'.

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

Improved Communication Between Multiple Processes

      There are many occasions when multiple processes on a given
machine want to communicate with each other and with processes on
other machines.  This can result in proliferation of process to
process communication links such as sockets or pipes.  The techniques
for using  these are well described and work well for communication
between individual pairs.  Unfortunately, they do not scale well and
can lead to  an explosion of required resources.  The disclosed
technique permits control of such growth by a simple protocol using
shared memory and 'semaphores'.

      Each process which wishes to communicate with others is
responsible for allocating a shared memory segment, a mutex object
and an event object (on AIX* these are all just semaphores).  These
three objects are all globally accessible to other processes on the
machine (with some security controls as available on the particular
operating system).  Typically, the 'id' of the shared memory segment
will be well known by being held in a file or derivable by driving
some interface on the process.  The shared memory segment is
organized such that the first few bytes of it constitute a fixed
length header which contains, among other things, the id of the two
semaphores.

      In operation the protocol is quite simple.  When a process
wishes to communicate with another the flow is as follows:
  o  If no communication has taken place, the 'communication
      setup' is:
     -  Build a memory segment and format the header.
     -  Build the mutex and save its id in the header.
     -  Build the event and save its id in the header.
     -  Optionally establish a thread to wait on the event object.
  o  If this is the first flow, the 'session setup' is:
     -  Find the shared memory address of the other process and
         map it into the current...