DOC PREVIEW
Berkeley COMPSCI 162 - Lecture 10 Tips for Handling Group Projects Thread Scheduling

This preview shows page 1-2-3-20-21-22-41-42-43 out of 43 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS162 Operating Systems and Systems Programming Lecture 10 Tips for Handling Group Projects Thread SchedulingReview: DeadlockReview: Resource Allocation Graph ExamplesReview: Methods for Handling DeadlocksReview: Train Example (Wormhole-Routed Network)Review: Banker’s Algorithm for Preventing DeadlockGoals for TodayTips for Programming in a Project TeamBig ProjectsTechniques for Partitioning TasksCommunicationCoordinationHow to Make it Work?Suggested Documents for You to MaintainUse Software ToolsTest ContinuouslyAdministriviaCPU SchedulingScheduling AssumptionsAssumption: CPU BurstsScheduling Policy Goals/CriteriaFirst-Come, First-Served (FCFS) SchedulingFCFS Scheduling (Cont.)Round Robin (RR)Example of RR with Time Quantum = 20Round-Robin DiscussionComparisons between FCFS and Round RobinEarlier Example with Different Time QuantumWhat if we Knew the Future?DiscussionExample to illustrate benefits of SRTFSRTF Example continued:SRTF Further discussionPredicting the Length of the Next CPU BurstMulti-Level Feedback SchedulingScheduling DetailsWhat about Fairness?Lottery SchedulingLottery Scheduling ExampleHow to Evaluate a Scheduling algorithm?A Final Word on SchedulingSummarySummary (2)CS162Operating Systems andSystems ProgrammingLecture 10Tips for Handling Group ProjectsThread SchedulingOctober 3, 2005Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 10.210/03/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Deadlock•Starvation vs. Deadlock–Starvation: thread waits indefinitely–Deadlock: circular waiting for resources–DeadlockStarvation, but not other way around•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»There exists a set {T1, …, Tn} of threads with a cyclic waiting patternLec 10.310/03/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Resource Allocation Graph ExamplesT1T2T3R1R2R3R4Simple ResourceAllocation GraphT1T2T3R1R2R3R4Allocation GraphWith DeadlockT1T2T3R2R1T4Allocation GraphWith Cycle, butNo Deadlock•Recall:–request edge – directed edge T1  Rj–assignment edge – directed edge Rj  TiLec 10.410/03/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Methods for Handling Deadlocks•Allow system to enter deadlock and then recover–Requires deadlock detection algorithm–Some technique for selectively preempting resources and/or terminating tasks•Ensure that system will never enter a deadlock–Need to monitor all lock acquisitions–Selectively deny those that might lead to deadlock•Ignore the problem and pretend that deadlocks never occur in the system–used by most operating systems, including UNIXLec 10.510/03/05 Kubiatowicz CS162 ©UCB Fall 2005Review: Train Example (Wormhole-Routed Network)•Circular dependency (Deadlock!)–Each train wants to turn right–Blocked by other trains–Similar problem to multiprocessor networks•Fix? Imagine grid extends in all four directions–Force ordering of channels (tracks)»Protocol: Always go east-west first, then north-south–Called “dimension ordering” (X then Y)DisallowedBy RuleLec 10.610/03/05 Kubiatowicz CS162 ©UCB Fall 2005•Monitor every request to see if it has the potential to lead to deadlock–Every thread must state a “maximum” expected allocation ahead of time–Keeps system in a “SAFE” state  there always exists a sequence {T1, T2, … Tn} with T1 able to request all its remaining resources and finish, then T2 able to request all its remaining resources and finish, etc..–Evaluate each request and grant if some ordering of threads is still deadlock free afterward »Technique: pretend each request is granted, then run deadlock detection algorithm, substituting [Maxnode]-[Allocnode] for [Requestnode]Grant request if result is deadlock free (conservative!)–Algorithm allows the sum of maximum resource needs of all current threads to be greater than total resourcesReview: Banker’s Algorithm for Preventing DeadlockLec 10.710/03/05 Kubiatowicz CS162 ©UCB Fall 2005Goals for Today•Tips for Programming in a Project Team•Scheduling Policy goals•Policy Options•Implementation ConsiderationsNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and GagneLec 10.810/03/05 Kubiatowicz CS162 ©UCB Fall 2005Tips for Programming in a Project Team•Big projects require more than one person (or long, long, long time)–Big OS: thousands of person-years!•It’s very hard to make software project teams work correctly–Doesn’t seem to be as true of big construction projects»Consider building the Empire state building: staging iron production thousands of miles away»Or the Hoover dam: built towns to hold workers–Ok to miss deadlines? »We make it free (slip days)»In reality they’re very expensive: time-to-market is one of the most important things!“You just have to get your synchronization right!”Lec 10.910/03/05 Kubiatowicz CS162 ©UCB Fall 2005Big Projects•What is a big project?–Time/work estimation is hard–Programmers are eternal optimistics (it will only take two days)!»This is why we bug you about starting the project early»Had a grad student who used to say he just needed “10 minutes” to fix something. Two hours later…•Can a project be efficiently partitioned?–Partitionable task decreases in time asyou add people–But, if you require communication:»Time reaches a minimum bound»With complex interactions, time increases!–Mythical person-month problem:»You estimate how long a project will take»Starts to fall behind, so you add more people»Project takes even more time!Lec 10.1010/03/05 Kubiatowicz CS162 ©UCB Fall 2005Techniques for Partitioning Tasks•Functional–Person A implements threads, Person B implements semaphores, Person C implements locks…–Problem: Lots of communication across APIs»If B changes the API, A may need to make changes»Story: Large airline company spent $200 million on a new scheduling and booking system. Two teams “working together.” After two years, went to merge software. Failed! Interfaces had changed (documented, but no one noticed). Result: would cost another $200 million to fix. •Task–Person A designs, Person B writes code, Person C tests–May be difficult to find right balance, but


View Full Document

Berkeley COMPSCI 162 - Lecture 10 Tips for Handling Group Projects Thread Scheduling

Documents in this Course
Lecture 1

Lecture 1

12 pages

Nachos

Nachos

41 pages

Security

Security

39 pages

Load more
Download Lecture 10 Tips for Handling Group Projects Thread Scheduling
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 10 Tips for Handling Group Projects Thread Scheduling and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 10 Tips for Handling Group Projects Thread Scheduling 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?