Browse Prior Art Database

THROTTLING ACTIVITY IN A MULTI-TASKING OPERATING SYSTEM

IP.com Disclosure Number: IPCOM000008433D
Original Publication Date: 1997-Dec-01
Included in the Prior Art Database: 2002-Jun-13
Document File: 3 page(s) / 186K

Publishing Venue

Motorola

Related People

Philip T. Fleege: AUTHOR [+2]

Abstract

Software designs and implementations of many computer systems are often broken down into func- tional software units, such that each unit is referred to as a "task". Each task is designed and implemented to control the processing of one or more specific areas of the computers' system features. Although, sometimes these system features are realized by the coordination of two or more tasks, ultimately, the processing is still localized and controlled within one specific task.

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 33% of the total text.

Page 1 of 3

MOTOROLA Technical Developments

THROTTLING ACTIVITY IN A MULTI-TASKING OPERATING SYSTEM

by Philip T. Fleege and Brian Jones

BACKGROUND

  Software designs and implementations of many computer systems are often broken down into func- tional software units, such that each unit is referred to as a "task". Each task is designed and implemented to control the processing of one or more specific areas of the computers' system features. Although, sometimes these system features are realized by the coordination of two or more tasks, ultimately, the processing is still localized and controlled within one specific task.

  To assign an importance (or priority), to a set of system features, the operating system can allocate each task a unique level of processing priority. This priority is referred to as the "task priority". The task priority is used to coordinate the run time execution of these tasks, thereby, ensuring that various system features, which are associated and controlled by each task, are scheduled and processed before other lower priority system features. When designed correctly, a computer systems' tasking priority scheme can result in all system features being real- ized in a predefined sequence of activity based upon tasking priority.

However, while a computer system is running, there are times when the system must change the

assigned importance (or priority), of a subset of sys- tem features. Recall that each systems' features are often localized and controlled within one specific task. But because the priority of on/y a few system features associated to a given task have changed, it is not viable to simply dynamically change the task priority of the corresponding task.

  The need to dynamically change the priority of a subset of system features, which are designed and implemented within an associated task, could, for instance, be "tied" to the computer systems' degree of loading, i.e. as the computer system becomes

more loaded and throughput begins to decrease, some system features may become less important and therefore need to be executed at a lower priority. Examples of these types of system features may include processing that creates excessive data I/O, memory "garbage" collection processing, or self- diagnostic and fault recovery processing.

  A similar scenario occurs when a system level requirement dictates that certain processing or activity should only occur after all other activity is completed, i.e. the activity is always considered to be lowest in importance. However, after investigat- ing all possible implementations, it is determined that this activity can only be implemented and/or processed within the context (or memory space), of a higher priority task!

  The same scenario described above can be restated in the following way. When a significant amount of less important processing must be accomplished within the context of a higher priority task, while at the same time introducing little or no impact on the computer sy...