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
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 Scheduling October 3 2005 Prof John Kubiatowicz http inst eecs berkeley edu cs162 Review 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 pattern 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 2 Review Resource Allocation Graph Examples Recall request edge directed edge T1 Rj assignment edge directed edge Rj Ti R1 T1 R2 T2 R3 R1 T3 T2 R3 R4 Simple Resource Allocation Graph 10 03 05 T1 R2 R1 T3 R4 Allocation Graph With Deadlock Kubiatowicz CS162 UCB Fall 2005 T1 T2 T3 R2 T4 Allocation Graph With Cycle but No Deadlock Lec 10 3 Review 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 UNIX 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 4 Review 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 ed w lo le al Ru is D By 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 5 Review Banker s Algorithm for Preventing Deadlock 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 resources 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 6 Goals for Today Tips for Programming in a Project Team Scheduling Policy goals Policy Options Implementation Considerations Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 7 Gagne Tips for Programming in a Project Team Big projects require more than one person or long long long time Big OS thousands of personyears 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 You just have Ok to miss deadlines to get your We make it free slip days synchronization right In reality they re very expensive 10 03 05 time to market is one of the most important things Kubiatowicz CS162 UCB Fall 2005 Lec 10 8 Big 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 as you add people But if you require communication Time reaches a minimum bound With complex interactions time increases Mythical person month problem 10 03 05 You estimate how long a project will take Starts to fall behind so you add more people Project takes evenCS162 more time Kubiatowicz UCB Fall 2005 Lec 10 9 Techniques 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 can focus on each person s strengths Theory vs systems hacker Since Debugging is hard Microsoft has two testers for each programmer Most CS162 project teams are functional but people have had success with task based divisions 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 10 Communication More people mean more communication Changes have to be propagated to more people Think about person writing code for most fundamental component of system everyone depends on them Miscommunication is common Index starts at 0 I thought you said 1 Who makes decisions Individual decisions are fast but trouble Group decisions take time Centralized decisions require a big picture view someone who can be the system architect Often designating someone as the system architect can be a good thing Better not be clueless Better have good people skills Better let other people do work 10 03 05 Kubiatowicz CS162 UCB Fall 2005 Lec 10 11 Coordination More people no one can make all meetings They miss decisions and associated discussion Example from earlier class one person missed meetings and did something group had rejected Why do we limit groups to 5 people You would never be able to schedule meetings Why do we require 3 or 4 people minimum You need to experience groups to get ready for real world People have different work styles Some people work in the morning some at night How do you decide when to meet or work together What about project slippage It will happen guaranteed Another example final project in CS152 everyone


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
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 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?