Week 04 Notes for CS 3750 -- Fall 2001

• Take Roll.
• Pass Back the homework and discuss it.
• Announcements
  • I posted a homework problem for chapter 6
  
  
  
• Check what's new in schedule
• Lecture Topics for chapter five -- Threads
  • What resources does a process need?
  • What individual resources does a thread need? Every other resource must be shared with the other threads in the process.
  • Discuss (so-called) benefits of multi-threading:
    • Responsiveness: A multi-threaded task may have better turnaround time -- elapsed time from submission to finish of task. This is because a single process can use CPU(s) *and* I/O channel(s) simultaneously. However the scheduling policy of the OS can work against this potential advantage.
    • Resource Sharing: The sharing of primary memory facilitates the communication of the threads of a task. The overall system benefits from the sharing of primary memory because more memory is available to run more programs. This can be viewed as something of a potential disadvantage to the individual task because it must share the CPU(s) with more tasks. Sharing of memory mapping information can make context switching go faster, but only when switching between threads of one task, not when switching from task to task. Therefore the scheduler has to do some special handling to get the benefit of fast context switching -- i.e. "batching" the threads of one task.
    • Economy: It is more economical to create a new thread in a task. It is more economical to switch from one thread to another within the same task.
    • Utilization of Multiprocessing: Multithreading allows the process to use more than one CPU simultaneously (assuming helpful scheduling).
  • User-level threads rely on library functions
  • User-level threads are generally faster to create and manage than kernel-level threads.
  • Unlike the case with kernel-level threads, the entire task generally has to block when a user-level thread does a blocking system call.
  • Question: Can it be made feasible to run tasks with relatively large numbers of I/O-bound user-level threads?
  • Discuss multithreading support models -- how user threads are supported by kernel threads: many-to-one model, one-to-one model, and many-to-many model.
  • How should fork-task and exec-task behave when called by a thread in a task?
  • What are (Unix) signals? What is the relation to interrupts and traps?
  • When a signal is sent to a multithreaded application, which thread should receive the signal and handle it? System designers have to make some decisions on how to answer this according to the type of signal sent. For example a signal to kill the process should probably go to all the threads. A "suspend" or "continue" signal might be intended for one particular thread.
  • Discuss thread pools (p. 138)
  • Care to look at example of pthread code on page #140?
  • Errata: It would seem the text slips up when it states: "Kernel-level threads are the only objects scheduled" on page 141, paragraph 2, line 4 but then says: ".. the kernel can then schedule another LWP ..." on page 142, paragraph 3, lines 6-7.
  • Discuss Solaris 2 Threads
  • Discuss Linux "Threads"
• Lecture Topics for Chapter Six -- Scheduling
  • What is a CPU burst?
  • What are preemptive and non-preemptive CPU scheduling?
    • When process X switches from running to waiting (e.g. waiting for I/O), the OS does not have the option to choose to dispatch X as the next process to run. (This is a case of NON-PREEMPTIVE scheduling)
    • When process X switches from running to ready (e.g. when an interrupt from some I/O device forces X out of the CPU), the OS DOES have the option to dispatch X as the next user process to run, OR NOT. (This is a case of PREEMPTIVE scheduling)
    • When process X switches from waiting to ready (e.g. when one of its I/O's completes), the OS DOES have the option to dispatch X as the next user process to run, OR NOT. (This is a case of PREEMPTIVE scheduling)
    • When process X terminates, the OS does not have the option to choose to dispatch X as the next process to run. (This is a case of NON-PREEMPTIVE scheduling)
  • Fact -- While executing "critical sections" of code, the operating system may rely on NOT being preempted to insure that the data it is changing is not accessed by another process until ready.
  • What is the job of the dispatcher module of an operating system?
  • Discuss goals of short-term scheduling: high CPU utilization, high throughput, short turnaround time, short waiting time, short response time.
    • throughput == jobs completed per unit time
    • turnaround == time from submission to completion
    • wait time == time spent in the ready queue
    • response time == time from submission to start of first response
  • What are these scheduling methods and what are some of their advantages and disadvantages?
    • FCFS -- easily understood and implemented -- non-preemptive -- can lead to long average waiting times -- is subject to the convoy effect.
    • SJF -- difficult to implement perfectly -- usually requires time estimates -- pure SJF gives minimum average wating time -- can be preemptive or non-preemptive -- if preemptive then when a shorter job enters the queue, the running job must be replace with the new job.
    • HPJF -- can be preemptive or non-preemptive -- can lead to starvation (SJF is a form of HPJF) -- aging used in conjunction with HPJF can avert starvation -- Unix is interesting in that "priority" is actuall based on "starvation" so low priority processes don't starve simply because starvation causes the priority to become higher
    • RR -- designed for time-sharing -- circular queue and time-slicing (quantizing) -- preemptive -- response times tend to be short -- average wait times tend to be high -- there tends to be a high amount of context-switching overhead -- to avoid excessive overhead we need the quanta to be large in comparison with the context-switch time -- to get low turnaround times the quanta should be larger than the average CPU burst time -- on the other hand the quanta has to be small enough to produce good response time
  • Discuss Multilevel Queue Scheduling -- different kinds of jobs at different priority levels -- a queue at each level with its own particular scheduling algorithm
  • Discuss Multilevel Feedback Queue Scheduling -- flexible but complex
  • Discuss Multiple-Processor Scheduling
    • per-processor ready queues versus single ready queue
    • single scheduler versus shared ready queue
  • Discuss real-time scheduling -- hard and soft
    • Soft real time scheduling
      • priority scheduling -- do not age real time processes
      • small dispatch latency
        • interruptible system calls
        • "safe" preemption points or interruptible kernel using critical section synchronization methods
        • priority inversion problem and priority-inheritance solution
  • Evaluation/selection of scheduling algorithm
    • describe and prioritize performance goals that are affected by scheduling, such as response time and throughput.
    • Evaluate using Deterministic modeling -- calculate performance based on specific test inputs
    • Evaluate using Queueing Models
      • prepare by gathering system statistics
        • distribution of CPU and I/O bursts
        • distribution of job arrival-time
      • do queueing network analysis -- get figures for things like average waiting time
      • the mathematics can be difficult so often researchers make simplifying assumptions
      • Naturally the results may be "weaker" because of the simplifying assumptions.
    • Evaluate using Simulations
      • represent major components and activities of the system with software functions and data structures.
      • use a variable to represent a clock and update system state variables after each "tick"
      • measure desired characteristics of the (simulation of the) system
      • use random numbers and assumed distributions to produce inputs to the system, or use traces from actual running systems
      • random numbers and assumed distributions may not capture enough information such as correlations in time between different kinds of events.
      • traces can take up a lot of space on secondary storage
      • simulations can be expensive to code and require long periods of time to run
    • Evaluation by Implementation -- implement a scheduling algorithm on an actual system and measure its performance
      • cost of coding
      • may be inconvenient to the userss
      • user behaviour may change in response to new scheduling algorithm so the benefits of the algorithm may not persist
      • it may be useful to allow managers and users to "tune" the scheduling policy of the running system.
  • Solaris2 Scheduling
    • priority scheduling -- four priority levels: real time, system, time-sharing, interactive
    • time sharing processes use a multilevel feedback queue
    • generally low priority processes get a larger time slice, and
    • higher priority processes get a smaller time slice
  • Windows 2000 Scheduling
    • priority based and preemptive
    • variable class with priorities 1 to 15
    • real-time class with priorities from 16 to 31
    • memory management has priority 0
    • priorities of threads in the variable class can change
    • if a thread in the variable class uses up its time quantum, its priority is lowered, but never below a certain base value
    • The dispatcher boosts the priority of a thread in the variable class when it is released from a wait queue
    • foreground processes that a user is interacting with have 3 times larger quantum than "background processes."
  • Linux scheduling
    • Linux has a time-sharing scheduling algorithm and a real-time scheduling algorithm
    • time-sharing algorithm uses a credit system -- constantly running processes tend to lose credits and processes that spend a lot of time waiting tend to gain credits.