Every program running on a computer whether it is a
background service or an application is called a process. As long as
von Neumann architecture is used to build a computer, only one
process per CPU can be run at one time.
Older computer operating systems such as MS-DOS did not try
to bypass this limit with the exception of interrupt processing and only
one process could be run under them. Mainframe operating systems
have had multi-tasking capabilities since the early 1960’s. Modern
operating systems enable concurrent execution of many processes at
once via multi-tasking even with one CPU.
Process management is an operating system’s way of dealing
with running multiple processes at once. Since most computers
contain one processor with one core, multi-tasking is done by simply
switching processes quickly. Depending on the operating system, as
more processes run, either each time slice will become smaller or
there will be a longer delay before each process given a chance to run.
Process management involves computing and distributing CPU
time as well as other resources. Most operating systems allow a
process to be assigned a priority which affects its allocation of CPU
time. Interactive operating systems also employ some level of
feedback in which the task with which the user is working receives
higher priority.
Interrupt driven processes will normally run at a very high
priority. In many systems, there is a background process such as the
System Idle Process in Windows which will run when no other process
is waiting for the CPU.
It's tempting to think of a process as an application, but that
gives an incomplete picture of how processes relate to the operating
system and hardware. The application you see (word processor,
spreadsheet or game) is, indeed, a process, but that application may
cause several other processes to begin, for tasks like communications
with other devices or other computers.
There are also numerous processes that run without giving you
direct evidence that they ever exist. For example, Windows XP and
UNIX can have dozens of background processes running to handle the
network, memory management, disk management, virus checking and
so on.
A process, then, is software that performs some action and can
be controlled -- by a user, by other applications or by the operating
system.
It is processes, rather than applications, that the operating
system controls and schedules for execution by the CPU. In a single-
tasking system, the schedule is straightforward. The operating system
allows the application to begin running, suspending the execution only
long enough to deal with interrupts and user input.
Interrupts are special signals sent by hardware or software to
the CPU. It's as if some part of the computer suddenly raised its hand
to ask for the CPU's attention in a lively meeting. Sometimes the
operating system will schedule the priority of processes so that
interrupts are masked -- that is, the operating system will ignore the
interrupts from some sources so that a particular job can be finished
as quickly as possible.
There are some interrupts such as those from error conditions or
problems with memory that are so important that they can't be
ignored. These non-maskable interrupts (NMIs) must be dealt with
immediately, regardless of the other tasks at hand.
While interrupts add some complication to the execution of
processes in a single-tasking system, the job of the operating system
becomes much more complicated in a multi-tasking system. Now, the
operating system must arrange the execution of applications so that
you believe that there are several things happening at once.
This is complicated because the CPU can only do one thing at a
time. In order to give the appearance of lots of things happening at
the same time, the operating system has to switch between different
processes thousands of times a second. Here's how it happens:
A process occupies a certain amount of RAM. It also makes
use of registers, stacks and queues within the CPU and
operating-system memory space.
When two processes are multi-tasking, the operating system
allots a certain number of CPU execution cycles to one
program.
After that number of cycles, the operating system makes
copies of all the registers, stacks and queues used by the
processes and note the point at which the process paused in
its execution.
It then loads all the registers, stacks and queues used by the
second process and allow it a certain number of CPU cycles.
When those are complete, it makes copies of all the registers,
stacks and queues used by the second program, and load the
first program.
All of the information needed to keep track of a process when
switching is kept in a data package called a process control block. The
process control block typically contains:
An ID number that identifies the process
Pointers to the locations in the program and its data where
processing last occurred
Register contents
States of various flags and switches
Pointers to the upper and lower bounds of the memory
required for the process
A list of files opened by the process
The priority of the process
The status of all I/O devices needed by the process
Each process has a status associated with it. Many processes
consume no CPU time until they get some sort of input. For example, a
process might be waiting on a keystroke from the user. While it is
waiting for the keystroke, it uses no CPU time. While it is waiting, it is
“suspended”.
When the keystroke arrives, the OS changes its status. When
the status of the process changes, from pending to active, for
example, or from suspended to running, the information in the process
control block must be used like the data in any other program to direct
execution of the task-switching portion of the operating system.
This process swapping happens without direct user interference,
and each process gets enough CPU cycles to accomplish its task in a
reasonable amount of time. Trouble can come, though, if the user tries
to have too many processes functioning at the same time. The
operating system itself requires some CPU cycles to perform the
saving and swapping of all the registers, queues and stacks of the
application processes.
If enough processes are started, and if the operating system
hasn't been carefully designed, the system can begin to use the vast
majority of its available CPU cycles to swap between processes rather
than run processes. When this happens, it's called thrashing, and it
usually requires some sort of direct user intervention to stop processes
and bring order back to the system.
One way that operating-system designers reduce the chance of
thrashing is by reducing the need for new processes to perform
various tasks. Some operating systems allow for a “process lite” called
a thread that can deal with all the CPU-intensive work of a normal
process, but generally does not deal with the various types of I/O and
does not establish structures requiring the extensive process control
block of a regular process. A process may start many threads or other
processes, but a thread cannot start a process.
So far, all the scheduling we've discussed has concerned a single
CPU. In a system with two or more CPUs, the operating system must
divide the workload among the CPUs, trying to balance the demands of
the required processes with the available cycles on the different CPUs.
Asymmetric operating systems use one CPU for their own needs
and divide application processes among the remaining CPUs.
Symmetric operating systems divide themselves among the various
CPUs, balancing demand versus CPU availability even when the
operating system itself is all that's running.
Even if the operating system is the only software with execution
needs, the CPU is not the only resource to be scheduled. Memory
management is the next crucial step in making sure that all processes
run smoothly.
background service or an application is called a process. As long as
von Neumann architecture is used to build a computer, only one
process per CPU can be run at one time.
Older computer operating systems such as MS-DOS did not try
to bypass this limit with the exception of interrupt processing and only
one process could be run under them. Mainframe operating systems
have had multi-tasking capabilities since the early 1960’s. Modern
operating systems enable concurrent execution of many processes at
once via multi-tasking even with one CPU.
Process management is an operating system’s way of dealing
with running multiple processes at once. Since most computers
contain one processor with one core, multi-tasking is done by simply
switching processes quickly. Depending on the operating system, as
more processes run, either each time slice will become smaller or
there will be a longer delay before each process given a chance to run.
Process management involves computing and distributing CPU
time as well as other resources. Most operating systems allow a
process to be assigned a priority which affects its allocation of CPU
time. Interactive operating systems also employ some level of
feedback in which the task with which the user is working receives
higher priority.
Interrupt driven processes will normally run at a very high
priority. In many systems, there is a background process such as the
System Idle Process in Windows which will run when no other process
is waiting for the CPU.
It's tempting to think of a process as an application, but that
gives an incomplete picture of how processes relate to the operating
system and hardware. The application you see (word processor,
spreadsheet or game) is, indeed, a process, but that application may
cause several other processes to begin, for tasks like communications
with other devices or other computers.
There are also numerous processes that run without giving you
direct evidence that they ever exist. For example, Windows XP and
UNIX can have dozens of background processes running to handle the
network, memory management, disk management, virus checking and
so on.
A process, then, is software that performs some action and can
be controlled -- by a user, by other applications or by the operating
system.
It is processes, rather than applications, that the operating
system controls and schedules for execution by the CPU. In a single-
tasking system, the schedule is straightforward. The operating system
allows the application to begin running, suspending the execution only
long enough to deal with interrupts and user input.
Interrupts are special signals sent by hardware or software to
the CPU. It's as if some part of the computer suddenly raised its hand
to ask for the CPU's attention in a lively meeting. Sometimes the
operating system will schedule the priority of processes so that
interrupts are masked -- that is, the operating system will ignore the
interrupts from some sources so that a particular job can be finished
as quickly as possible.
There are some interrupts such as those from error conditions or
problems with memory that are so important that they can't be
ignored. These non-maskable interrupts (NMIs) must be dealt with
immediately, regardless of the other tasks at hand.
While interrupts add some complication to the execution of
processes in a single-tasking system, the job of the operating system
becomes much more complicated in a multi-tasking system. Now, the
operating system must arrange the execution of applications so that
you believe that there are several things happening at once.
This is complicated because the CPU can only do one thing at a
time. In order to give the appearance of lots of things happening at
the same time, the operating system has to switch between different
processes thousands of times a second. Here's how it happens:
A process occupies a certain amount of RAM. It also makes
use of registers, stacks and queues within the CPU and
operating-system memory space.
When two processes are multi-tasking, the operating system
allots a certain number of CPU execution cycles to one
program.
After that number of cycles, the operating system makes
copies of all the registers, stacks and queues used by the
processes and note the point at which the process paused in
its execution.
It then loads all the registers, stacks and queues used by the
second process and allow it a certain number of CPU cycles.
When those are complete, it makes copies of all the registers,
stacks and queues used by the second program, and load the
first program.
All of the information needed to keep track of a process when
switching is kept in a data package called a process control block. The
process control block typically contains:
An ID number that identifies the process
Pointers to the locations in the program and its data where
processing last occurred
Register contents
States of various flags and switches
Pointers to the upper and lower bounds of the memory
required for the process
A list of files opened by the process
The priority of the process
The status of all I/O devices needed by the process
Each process has a status associated with it. Many processes
consume no CPU time until they get some sort of input. For example, a
process might be waiting on a keystroke from the user. While it is
waiting for the keystroke, it uses no CPU time. While it is waiting, it is
“suspended”.
When the keystroke arrives, the OS changes its status. When
the status of the process changes, from pending to active, for
example, or from suspended to running, the information in the process
control block must be used like the data in any other program to direct
execution of the task-switching portion of the operating system.
This process swapping happens without direct user interference,
and each process gets enough CPU cycles to accomplish its task in a
reasonable amount of time. Trouble can come, though, if the user tries
to have too many processes functioning at the same time. The
operating system itself requires some CPU cycles to perform the
saving and swapping of all the registers, queues and stacks of the
application processes.
If enough processes are started, and if the operating system
hasn't been carefully designed, the system can begin to use the vast
majority of its available CPU cycles to swap between processes rather
than run processes. When this happens, it's called thrashing, and it
usually requires some sort of direct user intervention to stop processes
and bring order back to the system.
One way that operating-system designers reduce the chance of
thrashing is by reducing the need for new processes to perform
various tasks. Some operating systems allow for a “process lite” called
a thread that can deal with all the CPU-intensive work of a normal
process, but generally does not deal with the various types of I/O and
does not establish structures requiring the extensive process control
block of a regular process. A process may start many threads or other
processes, but a thread cannot start a process.
So far, all the scheduling we've discussed has concerned a single
CPU. In a system with two or more CPUs, the operating system must
divide the workload among the CPUs, trying to balance the demands of
the required processes with the available cycles on the different CPUs.
Asymmetric operating systems use one CPU for their own needs
and divide application processes among the remaining CPUs.
Symmetric operating systems divide themselves among the various
CPUs, balancing demand versus CPU availability even when the
operating system itself is all that's running.
Even if the operating system is the only software with execution
needs, the CPU is not the only resource to be scheduled. Memory
management is the next crucial step in making sure that all processes
run smoothly.
Read more
No comments:
Post a Comment