[Home]History of Computer multitasking

HomePage | Recent Changes | Preferences

Revision 8 . . (edit) November 28, 2001 10:24 pm by Valery Beaud [Found some typos]
Revision 7 . . November 28, 2001 10:21 pm by The Anome [copyedit, wikiing]
Revision 6 . . November 28, 2001 9:33 pm by Rjstott [*Added real time to multitasking needs]
Revision 5 . . (edit) October 22, 2001 8:23 pm by Dachshund [typos]
  

Difference (from prior major revision) (minor diff, author diff)

Changed: 1c1
A method by which multiple tasks may execute, apparently simultaneously, on a single computer processor. Multitasking on a single CPU is accomplished by rapidly alternating between several active tasks, also known as processes?. These alternations, called "context switches", are either voluntarily initatiated by a running process, or by an external event such as a [hardware interrupt]?.
In computing, multitasking is a method by which multiple tasks may execute, apparently simultaneously, on a single computer processor. Multitasking on a single CPU is accomplished by rapidly alternating between several active tasks, also known as processes?. These alternations, called "context switches", are either voluntarily initatiated by a running process, or by an external event such as a [hardware interrupt]?.

Changed: 9c9
To remedy this situation, most time-sharing systems quickly evolved a more advanced approach known as [preemptive multitasking]?. On a such a system, a hardware system (not included on many early machines) can "interrupt" a running process, and direct the processor to execute a different piece of code. An system designed to take advantage of this feature need not rely on the voluntary ceding of processor time by individual processes. Instead, the hardware interrupt system can be set to "pre-empt" a running process and give control back to the operating system software, which can later restore the pre-empted process at exactly the point where it was interrupted. Programs "pre-empted" in such a manner need not explicitly give time to other processes; as far as a programmer is concerned, software programs can be written as though granted uninterrupted access to the CPU.
To remedy this situation, most time-sharing systems quickly evolved a more advanced approach known as [preemptive multitasking]?. On a such a system, a hardware system (not included on many early machines) can "interrupt" a running process, and direct the processor to execute a different piece of code. A system designed to take advantage of this feature need not rely on the voluntary ceding of processor time by individual processes. Instead, the hardware interrupt system can be set to "pre-empt" a running process and give control back to the operating system software, which can later restore the pre-empted process at exactly the point where it was interrupted. Programs "pre-empted" in such a manner need not explicitly give time to other processes; as far as a programmer is concerned, software programs can be written as though granted uninterrupted access to the CPU.

Changed: 13c13
At any specific time, processes can be grouped into two categories: those that are waiting for input or output (called "I/O bound"), and those that are fully utilizing the CPU ("CPU bound"). In early systems, processes would often "poll", or "busywait" while waiting requested input (such as disk, keyboard or network input.) During this time, the process was not performing useful work, but still maintained completely control of the CPU. With the advent of interrupts and preemptive multitasking, these I/O bound processes could be "blocked", or put on hold, pending the arrival of the necessary data, allowing other processes to utilize the CPU. As the arrival of the requested data would generate an interrupt, blocked processes could be guaranteed a timely return to execution.
At any specific time, processes can be grouped into two categories: those that are waiting for input or output (called "[I/O bound]?"), and those that are fully utilizing the CPU ("[CPU bound]?"). In early systems, processes would often "poll", or "busywait" while waiting requested input (such as disk, keyboard or network input.) During this time, the process was not performing useful work, but still maintained completely control of the CPU. With the advent of interrupts and preemptive multitasking, these I/O bound processes could be "blocked", or put on hold, pending the arrival of the necessary data, allowing other processes to utilize the CPU. As the arrival of the requested data would generate an interrupt, blocked processes could be guaranteed a timely return to execution.

Changed: 17c17
Another reason for multitasking was in the design of real time computing systems, where a number of possibly unrelated external activities needed to be controlled by a single processor system. In such systems a heirarchical interrupt system was coupled with process prioritisation to ensure that key activities were given a greater share of available process time.
Another reason for multitasking was in the design of real time computing systems, where a number of possibly unrelated external activities needed to be controlled by a single processor system. In such systems a hierarchical interrupt system was coupled with process prioritisation to ensure that key activities were given a greater share of available process time.

HomePage | Recent Changes | Preferences
Search: