Browse Prior Art Database

Program Serialization, Blocking Unwanted Events, Preventing Unbounded Waits

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

Publishing Venue

IBM

Related People

Hughes, D: AUTHOR

Abstract

Disclosed are two program interfaces and two supporting routines which provide a method for serialization among cooperating programs. A program that uses the interface to suspend processing declares which kinds of events can cause it to resume processing. The serialization mechanism prevents a suspended program from being notified of undesired events. The mechanism also prevents a program using it from waiting for an event that cannot occur. A program that generates an event can send an event notification to a cooperating program without knowing whether that program is waiting for the particular event.

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

Program Serialization, Blocking Unwanted Events, Preventing Unbounded Waits

      Disclosed are two program interfaces and two supporting
routines which provide a method for serialization among cooperating
programs.  A program that uses the interface to suspend processing
declares which kinds of events can cause it to resume processing.
The serialization mechanism prevents a suspended program from being
notified of undesired events.  The mechanism also prevents a program
using it from waiting for an event that cannot occur.  A program that
generates an event can send an event notification to a cooperating
program without knowing whether that program is waiting for the
particular event.

      There are essentially four parts to the invention.  The first
part is the detection that a program will be using the new interfaces
so that the necessary data structures can be put in place.  This is
done with no assistance from (or any awareness on the part of) the
programs that use the interfaces.  In general, this detection could
be done any time a program attempts to use either of the two
interfaces.  In the current implementation, it is done when an
end-user program invokes any of several system services that are
known to use the two interfaces described below.

      The next two parts are the two program interfaces that suspend
program execution and notify a program that an event has occurred.
For the sake of discussion, these interfaces are called Kernwait and
Kernpost, respectively.

      The Kernwait interface takes two arguments:  a function code
and an event list.  The function code is simply an integer which
takes any one of four values with meanings as follows:

o     suspend program execution until one of the events specified in
    the second argument occurs;

o     setup to put this program into a wait for any one of the events
    specified in the second argument, but do NOT suspend it;

o     wait (suspend) for any one of the events that were setup on a
    previous call;

o     cancel wait request.

      The event list is an integer which is the sum of several event
codes.  Each event code is assigned so that it has a single "one" bit
in its binary representation and to allow any number of events to be
added together without interfering with one another.  Thus, the
second argument is also a bit mask of the events that are allowed to
cause the waiting program to resume its execution.  The program can
resume (normal) execution only when it is notified of the occurrence
of one of the events in this event list.  The program is not notified
of the occurrence of events that are not specified in the event list.

      The Kernwait interface checks that the data structure it
requires is present.  In the current implementation, Kernwait
terminates the program if this structure is absent, but in the
general case, it could simply allocate the structure and continue.
The Kernwait inter...