Browse Prior Art Database

Method for Sharing Control Blocks Among Software Processes

IP.com Disclosure Number: IPCOM000106527D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 113K

Publishing Venue

IBM

Related People

Gayek, PW: AUTHOR [+2]

Abstract

Modern software engineering practices suggest that different processes in a software system pass necessary information to each other rather than access a common control block. A shared control block increases the coupling between the processes, making it more difficult to change one process without affecting the other, and in general increasing the complexity of the system.

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

Method for Sharing Control Blocks Among Software Processes

      Modern software engineering practices suggest that different
processes in a software system pass necessary information to each
other rather than access a common control block.  A shared control
block increases the coupling between the processes, making it more
difficult to change one process without affecting the other, and in
general increasing the complexity of the system.

      Nevertheless, there are many software systems which are under
memory and timing constraints, and cannot afford the time and space
required to send multiple copies of lengthy information between
processes.  In these systems, it makes sense to support only one copy
of a piece of information, but ways must be found to reduce the need
for coordination between the processes that share that information.

      This article describes an access technique used by multiple
processes to safely share a common control block.  In our system, the
control block represents a resource which is of long but finite
duration.  Hence, the control blocks are allocated from a "free pool"
and returned when the resource no longer exists.  The access
technique we developed solves the following particular problems:

o   The control block being physically freed more than once.

o   The control block being accessed after it has been freed.

o   The control block being accessed after it has been reused.

o   The control block being physically freed before all the processes
    are done using it.

      Note that our access technique does not address the problem of
multiple processes trying to access the same field of a control
block; this is a well understood lower-level problem solved with one
of the standard locking mechanisms.  However, the need is greatly
reduced for coordination in allocating/deallocating among processes
running at different interrupt priorities.

      The solution may be divided into two parts:  the control
structure and access function we defined, and the set of design rules
to which each cooperating process must adhere.

      All access to the control block pool is through a vector table,
with one table entry per control block, as shown in the Figure.  A
vector table entry is referenced through a resource identifier, which
is the only piece of information passed between processes to refer to
a control block.  This resource identifier consists of two parts:

o   A simple index into the vector table

o   An instance identifier

      The instance identifier of the resource represented by a
control block is a number which is incremented each time the control
block is reused, and therefore indicates which of N usages of the
resource is meant.  A process uses the access function to gain
addressability to a vector table entry, given the resource
identifier.  The vector table entry contains a pointer to the control
block, of course, but also contains a set of field...