Browse Prior Art Database

Multilevel Real Time Dispatching

IP.com Disclosure Number: IPCOM000078853D
Original Publication Date: 1973-Mar-01
Included in the Prior Art Database: 2005-Feb-26
Document File: 3 page(s) / 42K

Publishing Venue

IBM

Related People

Edel, TR: AUTHOR

Abstract

Various techniques are implemented in present day operating systems, which attempt to satisfy time-dependent requirements that exist in devices attached to Central Processing Units. That is, the nature of the devise requires that a program respond to an event generated by a device within a certain time period, in order for the device (or application) to function properly.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Multilevel Real Time Dispatching

Various techniques are implemented in present day operating systems, which attempt to satisfy time-dependent requirements that exist in devices attached to Central Processing Units. That is, the nature of the devise requires that a program respond to an event generated by a device within a certain time period, in order for the device (or application) to function properly.

Thus the time units which expire between software's sensing of an event until the first application program executed in response to that interrupt, is extremely critical. Prior efforts in mainline systems attempted to handle this problem, while at the same time creating others. The concept of an "I/O Appendage from Input/Output Supervisor (IOS) constituted a direct branch from Supervisor Code to Application Code. The disadvantages of this technique are as follows:
The Appendage operated disabled for any other events associated with devices which also had time-dependent requirements.

The Appendage operated in Supervisor State, Key Zero, thus exposing the security/integrity of the entire system to any user written appendage.

The Appendage could not request normal Operating System Services like:
SVC's (Supervisor Call)

Program Check Handling Machine Check Processing.

Therefore, what is required is a dispatching mechanism which directly associates an interrupt event with a problem program, that operates as any normal Operating System Task capable of requesting any System Service. The solution is a combination of Hardware/Software which associates an event with a Problem Program Task, which performs the following functions: Preserve the status (Program status word (PSW), Registers remaining clock time) of the pre-empted task.

Pushdown chain the preempted task in the stack list.

Check for an error.

Establish the interrupt mask field in a control register for the to be dispatched task. (taken from the task status block)

Set a time-out value for the to be dispatched task.

Set up the status save area, in case the to be dispatched task is itself preempted by a higher priority interrupt.

A Key item is the ability of Hardware to "save" a Software address specified at device Start I/O time, and to return that same value at interrupt time. This feature enables Software to directly associate the event to a system task, thus eliminating the otherwise required "table look-up" to associate a random-device address with an internal software table. This is schematically portrayed below:

The following system modifications are necessary in order to include such a feature in traditional operating systems that in...