Goals for Today CS162 Operating Systems and Systems Programming Lecture 8 Tips for Programming in a Project Team Discussion of Deadlocks Conditions for its occurrence Solutions for breaking and avoiding deadlock Tips for Working in a Project Team Cooperating Processes and Deadlock February 20 2008 Prof Anthony D Joseph http inst eecs berkeley edu cs162 Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and Gagne Gagne Many slides generated from my lecture notes by Kubiatowicz 2 20 08 Tips for Programming in a Project Team Time work estimation is hard Programmers are eternal optimistics it will only take two days Big OS thousands of person years It s very hard to make software project teams work correctly 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 Doesn t seem to be as true of big construction projects Can a project be efficiently partitioned Empire state building finished in one year staging iron production thousands of miles away Or the Hoover dam built towns to hold workers 2 20 08 Partitionable task decreases in time as you add people But if you require communication Time reaches a minimum bound With complex interactions time increases Is it OK to miss deadlines Mythical person month problem We make it free slip days Reality they re very expensive as time to market is one of the most important things Joseph CS162 UCB Spring 2008 Lec 8 2 Big Projects What is a big project Big projects require more than one person or long long long time You just have to get your synchronization right Joseph CS162 UCB Spring 2008 Lec 8 3 2 20 08 Page 1 You estimate how long a project will take Starts to fall behind so you add more people Project takes even more time Joseph CS162 UCB Spring 2008 Lec 8 4 Techniques for Partitioning Tasks Defensive Programming Like defensive driving but for code Functional Avoid depending on others so that if they do something unexpected you won t crash survive unexpected behavior Person A implements threads Person B implements semaphores Person C implements locks Problem Lots of communication across APIs Software engineering focuses on functionality 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 Given correct inputs code produces useful correct outputs Security cares about what happens when program is given invalid or unexpected inputs Shouldn t crash cause undesirable side effects or produce dangerous outputs for bad inputs Task Defensive programming 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 Apply idea at every interface or security perimeter So each module remains robust even if all others misbehave General strategy Assume attacker controls module s inputs make sure nothing terrible happens Most CS162 project teams are functional but people have had success with task based divisions 2 20 08 Joseph CS162 UCB Spring 2008 2 20 08 Lec 8 5 Communication Joseph CS162 UCB Spring 2008 Coordination More people no one can make all meetings 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 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 Index starts at 0 I thought you said 1 Why do we require 4 people minimum You would never be able to schedule meetings otherwise Miscommunication is common You need to experience groups to get ready for real world Who makes decisions People have different work styles Individual decisions are fast but trouble Group decisions take time Centralized decisions require a big picture view someone who can be the system architect 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 Ex phase 4 everyone busy but not talking One person way behind No one knew until very end too late 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 2 20 08 Joseph CS162 UCB Spring 2008 Lec 8 6 Hard to add people to existing group Members have already figured out how to work together Lec 8 7 2 20 08 Page 2 Joseph CS162 UCB Spring 2008 Lec 8 8 How to Make it Work People are human Get over it Suggested Documents for You to Maintain Project objectives goals constraints and priorities Specifications the manual plus performance specs People will make mistakes miss meetings miss deadlines etc You need to live with it and adapt It is better to anticipate problems than clean up afterwards This should be the first document generated and the last one finished Document document document Meeting notes Why Document Document all decisions You can often cut paste for the design documents Expose decisions and communicate to others Easier to spot mistakes early Easier to estimate progress Schedule What is your anticipated timing What to document This document is critical Everything but don t overwhelm people or no one will read Organizational Chart Standardize Who is responsible for what task One programming format variable naming conventions tab indents etc Comments Requires effects modifies javadoc 2 20 08 Joseph CS162 UCB Spring 2008 2 20 08 Lec 8 9 Taming Complexity with Abstractions Source revision control software Goal independently design implement and test each component Added benefit better security through isolation But components must work together in the final system The boundaries between components and people To isolate them from one another To ensure the final system actually works CVS Subversion others Easy to go back and see history undo mistakes Figure out where and why a bug got introduced Communicates changes to everyone use CVS s features Write scripts for non interactive software Use expect for interactive software JUnit automate unit
View Full Document
Unlocking...