| CS 321 Spring 2013 > Lecture Notes for Monday, February 18, 2013 |
In a concurrent/parallel program, a serial bottleneck is a part of the code in which all processes must wait for a single process. This can be a problem, since it reduces efficiency of multiprocessor architectures.
A barrier is a serial bottleneck deliberately introduced as a synchronization mechanism.
History: initially all computers were single-process. Then came multitasking (a.k.a. concurrency), both batch and interactive. PCs were initially single-process. Today most common OSs support concurrency. Since there are more processes than processors, decisions must be made about which processes run, and when. This is process scheduling.
For simplicity, we consider a process that is blocked for any reason, to be doing I/O. Processes switch between computation, I/O. A process that spends most of its time doing computation is compute bound. A process that spends most of its time blocked is I/O bound. A key factor is the length of a compute burst. I/O time does not depend on processor load. Processor speed increases lead to more I/O-bound processes.
Scheduling decision: which process to run next. Such decisions are made on process creation (run the new process now?), process termination, blocking, and when the regular mechanism for process switching is applied. This last can be voluntary or involuntary. When processes need to voluntarily relinquish control, we have nonpreemptive multitasking (e.g., original MacOS). When process switching is accomplished without any action by the process, via an interrupt, we have preemptive multitasking; most OSs today do this.
We look at process scheduling in three kinds of environments. Batch processing is when a computer is given multiple tasks, and it performs them without directly interacting with humans. Examples include render farms for large-scale graphics computation, and things like payroll runs at large corporations. Interactive processing is what we are most familiar with. A computer interacts with a human; in doing so, it has many tasks to perform. Real-Time processing makes strong guarantees about when processes execute. Examples might include military or security applications, medical devices, and various sensors or monitoring devices (rocket telemetry?).
Real-time guarantees can be very difficult to enforce. And if we are in a situation in which we cannot absolutely make the guarantee, then the real-time system cannot execute. This is why certain applications that would seem to be real-time in nature (video playback, many games, etc.) are generally run in an interactive environment.
Goals for process scheduling.
ggchappell@alaska.edu