CS5460: Operating Systemscs5460/slides/Lecture06.pdf · CS 5460: Operating Systems Lecture 6...

CS 5460: Operating Systems Lecture 6

CS5460: Operating Systems Lecture 6: Threads and Scheduling

(Chapters 4-5)

Last Time   Processes and threads:

–  Encapsulate resources and accounting –  Threads separate “execution context” from process abstraction –  Typical address space layout –  Context switch –  Kernel threads versus User threads

  How do threads communicate (within a process)?   How to cooperating processes communicate?   Synchronization is hard and important



P2

Timeline of a Context Switch P1

PN

P1

Save/restore cpu state

Save/restore cpu state

Scheduler (P1)

Scheduler (P1)

Scheduler (P2)

Scheduler (PN)

Interrupt or trap

Interrupt or trap

int/trap handler

One instr later!

int/trap handler

Return from trap/int (P2)

TIME

Question: What parts of timeline are inside kernel vs in user space?


  Threads separate process into two abstractions: –  Shared resources: address space, kernel resources, privileges –  Execution state: PC, SP, PSW, registers, stack, …

Address space

Thread

DOS, Small embedded systems

Real-time OSes, Java

Older (unthreaded) UNIX

Multihreaded OSes (Win7, OS X, Linux)

Add Multi- threading

Add multiprogramming


Implementing Threads   Address space shared by threads

–  Code –  Data and heap

  Thread private state: –  Registers (inc. pc, sp, psw) –  Stack

  Key issue: –  How do you safely access “shared” state?

»  Read-only (e.g., code) à easy »  Writable à hard

–  Whole section of course dedicated to this »  Synchronization »  Concurrency control

  Context switch between threads –  Save/restore registers (tricky)

Code:

Data:

SP0 Stack:

HP

PC0

PC1

SP1 Stack:

Today   Finish up thread discussion   Dispatching   Scheduling

–  What to run now? –  This answer is surprisingly complicated



Why Use Threads?   Multithreading can provide benefits:

–  Improved performance by overlapping activities –  Simpler program structure by separating activities

  Problems arise: –  New failure modes introduced à concurrency control –  Errors often far harder to debug, or even to reproduce –  Thread termination can be very tricky

  Multiprogramming vs. Multithreading –  Multiprogramming:

»  Higher overheads but greater isolation –  Multithreading:

»  Cooperation via shared memory à tighter integration »  Faster context switches


Simplistic Threads Pseudo-Example SharedBuffer input[N];

Shared BigStruct gamestate;

main() {

CreateThread(Listen);

CreateThread(Update);

CreateThread(Display);

}

Listen() {

Set up receive ports;

while (1) {

Recv(msg);

InsertBuf(input, msg);

}

}

Update() {

while (1) {

msg = ReadBuf(input);

ProcessMsg(msg);

UpdateState(&gamestate);

}

}

Display() {

while (1) {

ReadState(&gamestate);

UpdateDisplay();

Sleep(~30 msecs);

}

}


Simplistic Threads Example SharedBuffer input[N];

Shared BigStruct gamestate;

main() {

CreateThread(Listen);

CreateThread(Update);

CreateThread(Display);

}

Listen() {

Set up receive ports;

while (1) {

Recv(msg);

InsertBuf(input, msg);

}

}

Update() {

while (1) {

msg = ReadBuf(input);

ProcessMsg(msg);

UpdateState(&gamestate);

}

}

Display() {

while (1) {

ReadState(&gamestate);

UpdateDisplay();

Sleep(~30 msecs);

}

}

Shared variables

Create threads

Listener thread: Receives user inputs

Update thread: Calculates new game state (game logic)

Display thread: Updates display 30 times per sec.


Discussion   How do the different threads communicate?

–  Typically, directly accessing shared variables (shared memory) –  Problem: Managing all that concurrency

  In what order do the various threads run? –  Unless programmer intervenes (see below), fairly random

  What can go wrong? –  Race conditions, corrupted data, chaos!

  How do you ensure things happen in a “sane” order? –  Synchronization à our second major topic, starting soon


Changing Topic…   Done with threads for today

  Now: Dispatching and scheduling –  Dispatcher is the mechanism that context switches (mechanism) –  Scheduler decides what to run next (policy)


Introduction to Scheduling   Multiprogramming: running more than one program

at a time to increase utilization and throughput   Dispatching: context switch mechanism   Scheduling: policy that chooses what to run next

/* The core OS dispatch loop */

while (1) {

Choose new process to run

Save state of running process

Load state of new process on CPU

Resume new process

}

Terminated New

Ready Running

Waiting

create process

exit process

schedule

deschedule block on timer,

I/O, page fault, … I/O done


Dispatcher   What makes the “dispatcher” get control of CPU?

–  Internal events: running thread does something to block itself –  External events: interrupt causes ‘trap’ to kernel

  Example internal events: –  Thread blocks on I/O (e.g., waits for disk, mouse, …) –  Thread blocks waiting on another thread (e.g., msgrcv() or lock)

  Example external events: –  I/O device interrupt –  Timer interrupt: fallback to “force” threads to relinquish control

»  At core of “preemptive scheduling”

  How does the dispatcher actually get control? –  The OS has an internal “dispatch()” function that is called


Preemptive vs Non-Preemptive   Preemptive scheduling

+  OS can take away CPU from process w/o warning +  Must carefully save away process state so it can be resumed with

no visible impact of preemption +  Lets OS enforce scheduling policies +  Stronger fairness guarantees +  Solves infinite loop problem –  Increases scheduling overhead (timer interrupt) –  Complicates synchronization –  How often should you preempt? Scheduling quantum

  Most modern OSes employ preemptive scheduling –  Real time OSes sometimes avoid it


Scheduling   How should we pick which thread to run next?

–  First-come, first-served (FCFS)? –  Round robin? –  Shortest time remaining? –  Thread with highest priority? (If so, how do you compute priority?)

  Many criteria to consider: –  CPU utilization –  Throughput –  Response time –  Variance and outliers –  Fairness –  Multiple users

Which criteria are most (least) important depends on system! Consider: - batch vs interactive - real-time vs conventional - PC vs cell phone


First-come, First-served (FCFS)   First-come, first-served (FCFS) – non-preemptive

–  Execute jobs to completion in order they arrive –  Jobs relinquish CPU only when they finish or block on I/O –  Advantages:

»  Simple and somewhat fair –  Disadvantages:

»  Short jobs get stuck behind long jobs »  CPU bound jobs keep I/O-bound jobs from utilizing I/O

Proc Time Len P1 0 8 P2 1 4 P3 2 9 P4 3 5

0 8 12 21 26

Time

P1

P4 P3

P2

P2 P3 P4


Shortest Job First (SJF)   Shortest Job First (SJF) – non-preemptive

–  Good throughput, not fair –  Advantages:

»  Optimal with respect to waiting time –  Disadvantages:

»  Long jobs starve, requires advance knowledge of execution times –  Preemptive version: Shortest Remaining Time First (SRTF) –  Question: How do you determine which job is shortest?

»  Ask users? What about interactive applications?

Proc Time Len P1 0 8 P2 1 4 P3 2 9 P4 3 5

0 8 12 17 26

Time

P1

P3 P4

P2

P2 P3 P4


Round Robin   Round robin scheduling:

–  Divide CPU time into “scheduling quanta” (Question: How long?) –  Timer interrupt fires at end of each scheduling quantum –  If process blocks or quantum expires:

»  Move current process to end of ready queue »  Run process at head of the ready queue

–  Advantages: »  Very fair, long jobs do not indefinitely starve short ones or vice versa

–  Disadvantages: »  Average waiting time can be bad, I/O-bound processes suffer (why?)

Proc Time Len P1 0 8 P2 1 4 P3 2 9

0 11 21 Time P2 P3

P2 completes

19

P1 completes P3 completes


Priority Scheduling   At all times, run the highest priority runnable

process   But now the problem is assigning priorities!

–  Ask users? –  Set them ahead of time? –  Tough to make this work on a shared machine!

  Most other scheduling policies can be expressed using priorities

  Embedded OSes usually use priority scheduling –  Why does this work in that domain?

  Rate monotonic scheduling: Processes with shorter response time requirements get higher priority


Proportional Share Schedulers   Every thread has a scheduling “weight”

–  Over time, thread’s % of CPU ≈ weight/total_weight –  Threads weights (P1:10, P2:20, P3:20) à What share does P2 get?

  Example implementation –  Every thread has a “virtual time” –  Virtual time increases when a thread runs (e.g., increase time by

1/weight each quantum) –  Scheduling algorithm: Run thread with smallest virtual time

  Advantages: –  Priority-based scheduling w/o starvation –  Thread performance degrades gracefully as load increases

  Disadvantages: –  May lead to long waiting times (why?) –  CPU-bound and I/O-bound threads treated the same

Multilevel Feedback Queues   Run highest priority process at any given time   Vary priority of processes dynamically based on

observed behavior –  Give a priority boost to processes when they wake up from being

blocked on I/O –  Degrade process as it stays on the CPU

  Goals: –  High throughput for batch jobs –  Quick response time for interactive jobs –  No need to specify in advance whether a job is batch or

interactive

  This is how nearly all desktop and server OSes work



Real-Time Schedulers   Real-time application à needs to complete on time   Hard real-time:

–  Job really needs to complete on time or loss of life/money/… –  Examples: weapon systems, brake control, fly-by-wire avionics

  Soft real-time: –  Missing deadline causes annoying glitches –  Example: audio, video, games

  Key OS issue à deterministic scheduling! –  When high priority job is ready à must meet time bounds –  All system calls return in bounded time –  Unix and Windows are poor platforms for RT apps à why?


Real-Time Schedulers   Real-time ≠ fast   Most important real-time scheduling algorithm

–  Rate monotonic scheduling: Jobs with shorter response time requirements get higher priority

–  Examples?


Priority Inversion

  What if a high priority thread needs to acquire a resource owned by a low priority process

–  This happened on the Mars Pathfinder spacecraft –  Computer kept rebooting, made it hard to get work done

  One solution: –  Let low priority processes run at the priority of any high priority

process waiting on them –  How would you implement this?

  Other solutions?


Scheduling Summary   Non-preemptive scheduling

–  Useful when throughput is key issue à batch processing –  FCFS –  SJF

  Preemptive scheduling –  Useful when response time and fairness matter à interactive –  Round robin (q à ∝: FCFS, q à 0: high switching overhead) –  Priority scheduling –  Multi-level/dynamic priority scheduling –  Proportional share scheduling

  Real-time scheduling –  Useful when applications have time bounds needs/desires

More Scheduling Summary   What is the scheduler’s role on a lightly loaded

machine?

  When an OS is changed to support multiple threads per process, how should the scheduler be changed?


Important From Today   The dispatcher is a mechanism   The scheduler implements a policy

–  The question is: What to run now? –  Answer: Depends on what we’re trying to do

  Scheduler for a special-purpose embedded OS may be very simple

  Scheduler for a general-purpose OS is complicated because this kind of OS tries to do many things well


CS5460: Operating Systemscs5460/slides/Lecture06.pdf · CS 5460: Operating Systems Lecture 6...

Documents

Transcript of CS5460: Operating Systemscs5460/slides/Lecture06.pdf · CS 5460: Operating Systems Lecture 6...