Browse Prior Art Database

Dual Level Wait

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

Publishing Venue

IBM

Related People

Bender, S: AUTHOR [+2]

Abstract

Disclosed is a method for modifying the conditions under which a suspended process may resume execution and for maintaining accurate process status for the suspended process. The method avoids causing the process to resume execution and provides accurate process status though there may be multiple, asynchronous events that change the status and the conditions under which it may assume execution.

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

Dual Level Wait

      Disclosed is a method for modifying the conditions under which
a suspended process may resume execution and for maintaining accurate
process status for the suspended process.  The method avoids causing
the process to resume execution and provides accurate process status
though there may be multiple, asynchronous events that change the
status and the conditions under which it may assume execution.

      The invention is a combination of existing system services and
newly-created programs.  The invention was developed for IBM's
Multiple Virtual Storage (MVS) operating system, but it would work on
any operating system that provides similar functions.  The existing
services that the invention uses are the Schedule, Schedxit, and Wait
functions provided by MVS.  The new program services are called
Kernwait and Signal Manager and they use a shared data structure to
maintain the correct process status.

      The Figure shows a finite-state diagram with three states for a
suspended process.  The states are labeled S1, S2 and S3.  There are
three actions that trigger state transitions:

1.    When a process suspends, it lists in the shared data structure
    the events that will cause it to resume processing.  The arrival
    of such an event is denoted in the Figure as "EVENT" and it
    causes a state transition, either from S1 to "Resume" or from S2
    to S3.

2.    Under certain circumstances, one process may send another
    process a "stop signal", denoted SIGSTOP in the figure, which
    causes the target process to remain suspended until it receives a
    "continue signal."  The arrival of a SIGSTOP signal causes the
    state transitions shown in the figure.

3.    The "continue signal," denoted SIGCONT, which undoes the
    effects of a SIGSTOP, causes the state transitions shown in the
    figure.

      A suspended process in state S1 is said to be "waiting", but a
suspended process in either S2 or S3 is said to be "stopped."  The
core of this disclosure is the interaction between the Signal Manager
and Kernwait services.  This interaction provides the mechanism for
changing the state of the suspended process, for adding additional
conditions which must be met before it may resume execution, and for
correctly reporting the process status, all without having to
"unsuspend" the process.  Note: Although the figure shows only three
states for a suspended process, any number of suspended states is
possible.

      The program that suspends a process uses a data structure that
tells which events will cause the process to resume execution.  The
Kernwait service puts this information into the shared data
structure.  The Signal Manager has access to the data structure for a
process and when it receives a SIGSTOP for the process, the Signal
Manager determines whether the process has already suspended
execution.  If so, the Signal...