1 / 19

CS 162 Discussion Section Week 4 9/30 - 10/4

CS 162 Discussion Section Week 4 9/30 - 10/4. Today’s Section. Project administrivia Quiz Lecture Review Worksheet and Discussion. Project 1. Autograder is up submit proj1-test Due 10/8 (Tuesday) at 11:59 PM submit proj1-code Due 10/ 9 ( Wednesday ) at 11:59 PM

steve
Télécharger la présentation

CS 162 Discussion Section Week 4 9/30 - 10/4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 162 Discussion SectionWeek 4 9/30 - 10/4

  2. Today’s Section • Project administrivia • Quiz • Lecture Review • Worksheet and Discussion

  3. Project 1 • Autograder is up submit proj1-test • Due 10/8 (Tuesday) at 11:59 PM submit proj1-code • Due 10/9 (Wednesday) at 11:59 PM Final design doc & Project 1 Group Evals • Questions?

  4. Quiz…

  5. Name the conditions causing deadlock, given definitions(0.5 points each): thread holding at least one resource waits to acquire other resources held by other threads only one thread at a time can use a resource resource only released voluntarily by the thread holding it after done using the resource chain of n threads T(i); T(i) depends on T(i+1); T(n) depends on T(0) (True/False) Starvation implies deadlock Deadlock implies starvation (that a thread waits indefinitely) To find general deadlocks, it is enough to look for loops in the resource allocation graph.

  6. Lecture Review

  7. Thread A Wait For Owned By Res 2 Res 1 Owned By Wait For Thread B Starvation vs Deadlock • Starvation vs. Deadlock • Starvation: thread waits indefinitely • Example, low-priority thread waiting for resources constantly in use by high-priority threads • Deadlock: circular waiting for resources • Thread A owns Res 1 and is waiting for Res 2Thread B owns Res 2 and is waiting for Res 1 • Deadlock  Starvation but not vice versa • Starvation can end (but doesn’t have to) • Deadlock can’t end without external intervention

  8. Four requirements for Deadlock • Mutual exclusion • Only one thread at a time can use a resource • Hold and wait • Thread holding at least one resource is waiting to acquire additional resources held by other threads • No preemption • Resources are released only voluntarily by the thread holding the resource, after thread is finished with it • Circular wait • There exists a set {T1, …, Tn} of waiting threads • T1 is waiting for a resource that is held by T2 • T2 is waiting for a resource that is held by T3 • … • Tn is waiting for a resource that is held by T1

  9. R1 T2 T1 T3 R2 T4 Deadlock Detection Algorithm • Only one of each type of resource  look for loops • More General Deadlock Detection Algorithm • Let [X] represent an m-ary vector of non-negative integers (quantities of resources of each type): [FreeResources]: Current free resources each type[RequestX]: Current requests from thread X[AllocX]: Current resources held by thread X • See if tasks can eventually terminate on their own [Avail] = [FreeResources] Add all nodes to UNFINISHED do { done = true Foreach node in UNFINISHED { if ([Requestnode] <= [Avail]) { remove node from UNFINISHED [Avail] = [Avail] + [Allocnode] done = false } } } until(done) • Nodes left in UNFINISHED  deadlocked

  10. Banker’s Algorithm for Preventing Deadlock • Toward right idea: • State maximum resource needs in advance • Allow particular thread to proceed if: (available resources - #requested)  max remaining that might be needed by any thread • Banker’s algorithm (less conservative): • Allocate resources dynamically • Evaluate each request and grant if some ordering of threads is still deadlock free afterward • Keeps system in a “SAFE” state, i.e. there exists a sequence {T1, T2, … Tn} with T1 requesting all remaining resources, finishing, then T2 requesting all remaining resources, etc.. • Algorithm allows the sum of maximum resource needs of all current threads to be greater than total resources

  11. Banker’s Algorithm • Technique: pretend each request is granted, then run deadlock detection algorithm, substitute ([Requestnode] ≤ [Avail])  ([Maxnode]-[Allocnode] ≤ [Avail]) [FreeResources]: Current free resources each type [MaxX]: Max resources requested by thread X [AllocX]: Current resources held by thread X [Avail] = [FreeResources] Add all nodes to UNFINISHED do { done = trueForeachnode in UNFINISHED { if ([Maxnode]–[Allocnode] <= [Avail]) { remove node from UNFINISHED [Avail] = [Avail] + [Allocnode] done = false } } } until(done)

  12. Summary: Deadlock • Starvation vs. Deadlock • Starvation: thread waits indefinitely • Deadlock: circular waiting for resources • Four conditions for deadlocks • Mutual exclusion • Only one thread at a time can use a resource • Hold and wait • Thread holding at least one resource is waiting to acquire additional resources held by other threads • No preemption • Resources are released only voluntarily by the threads • Circular wait •  set {T1, …, Tn} of threads with a cyclic waiting pattern • Deadlock preemption • Deadlock prevention (Banker’s algorithm)

  13. Scheduling Metrics • Waiting Time: time the job is waiting in the ready queue • Time between job’s arrival in the ready queue and launching the job • Service (Execution) Time: time the job is running • Response (Completion) Time: • Time between job’s arrival in the ready queue and job’s completion • Response time is what the user sees: • Time to echo a keystroke in editor • Time to compile a program Response Time = Waiting Time + Service Time • Throughput: number of jobs completed per unit of time • Throughput related to response time, but not same thing: • Minimizing response time will lead to more context switching than if you only maximized throughput

  14. Scheduling Policy Goals/Criteria • Minimize Response Time • Minimize elapsed time to do an operation (or job) • Maximize Throughput • Two parts to maximizing throughput • Minimize overhead (for example, context-switching) • Efficient use of resources (CPU, disk, memory, etc) • Fairness • Share CPU among users in some equitable way • Fairness is not minimizing average response time: • Better average response time by making system less fair

  15. Summary • Scheduling: selecting a process from the ready queue and allocating the CPU to it • FCFS Scheduling: • Run threads to completion in order of submission • Pros: Simple (+) • Cons: Short jobs get stuck behind long ones (-) • Round-Robin Scheduling: • Give each thread a small amount of CPU time when it executes; cycle between all ready threads • Pros: Better for short jobs (+) • Cons: Poor when jobs are same length (-)

  16. Summary (cont’d) • Shortest Job First (SJF)/Shortest Remaining Time First (SRTF): • Run whatever job has the least amount of computation to do/least remaining amount of computation to do • Pros: Optimal (average response time) • Cons: Hard to predict future, Unfair • Multi-Level Feedback Scheduling: • Multiple queues of different priorities • Automatic promotion/demotion of process priority in order to approximate SJF/SRTF • Lottery Scheduling: • Give each thread a number of tokens (short tasks  more tokens) • Reserve a minimum number of tokens for every thread to ensure forward progress/fairness

  17. Worksheet…

  18. Name the conditions causing deadlock, given definitions(0.5 points each): • chain of n threads T(i); T(i) depends on T(i+1); T(n) depends on T(0) • thread holding at least one resource waits to acquire other resources held by other threads • resource only released voluntarily by the thread holding it after done using the resource • only one thread at a time can use a resource (True/False) • Deadlock implies starvation (that a thread waits indefinitely) • Starvation implies deadlock • To find general deadlocks, it is enough to look for loops in the resource allocation graph.

More Related