Unformatted text preview:

Review Definition of Monitor Semaphores are confusing because dual purpose CS162 Operating Systems and Systems Programming Lecture 9 Both mutual exclusion and scheduling constraints Cleaner idea Use locks for mutual exclusion and condition variables for scheduling constraints Monitor a lock and zero or more condition variables for managing concurrent access to shared data Tips for Working in a Project Team Cooperating Processes and Deadlock Use of Monitors is a programming paradigm Lock provides mutual exclusion to shared data Always acquire before accessing shared data structure Always release after finishing with shared data February 16 2010 Ion Stoica http inst eecs berkeley edu cs162 Condition Variable a queue of threads waiting for something inside a critical section Key idea allow sleeping inside critical section by atomically releasing lock at time we go to sleep Contrast to semaphores Can t wait inside critical section 2 16 10 Review Monitors C language Pretty straightforward synchronization Wait if necessary Signal when change something so any waiting threads can proceed Just make sure you know all the code paths out of a critical section Basic structure of monitor based program int Rtn lock acquire if exception lock release return errReturnCode lock release return OK Check and or update state variables Wait if necessary do something so no need to wait lock condvar signal Lec 9 2 C Language Support for Synchronization Monitors represent the logic of the program lock while need to wait condvar wait unlock CS162 UCB Fall 2010 Check and or update state variables unlock 2 16 10 CS162 UCB Fall 2010 2 16 10 Lec 9 3 Page 1 CS162 UCB Fall 2010 Lec 9 4 C Language Support for Synchronization C Language Support for Synchronization con t Must catch all exceptions in critical sections Languages with exceptions like C Catch exceptions release lock and re throw exception Languages that support exceptions are problematic easy to make a non local exit without releasing lock Consider void Rtn lock acquire try DoFoo catch lock release throw lock release void DoFoo if exception throw void Rtn lock acquire DoFoo lock release void DoFoo if exception throw errException Notice that an exception in DoFoo will exit without releasing the lock 2 16 10 CS162 UCB Fall 2010 2 16 10 Lec 9 5 Can deallocate free lock regardless of exit method CS162 UCB Fall 2010 Lec 9 6 Java Language Support for Synchronization con t Java also has synchronized statements Java has explicit support for threads and thread synchronization Bank Account example synchronized object class Account private int balance object constructor public Account int initialBalance balance initialBalance public synchronized int getBalance return balance public synchronized void deposit int amount balance amount Since every Java object has an associated lock this type of statement acquires and releases the object s lock on entry and exit of the body Works properly even with exceptions synchronized object DoFoo void DoFoo throw errException Every object has an associated lock which gets automatically acquired and released on entry and exit from a synchronized method CS162 UCB Fall 2010 errException Even Better auto ptr T facility See C Spec Java Language Support for Synchronization 2 16 10 catch exception release lock re throw the exception 2 16 10 Lec 9 7 Page 2 CS162 UCB Fall 2010 Lec 9 8 Java Language Support for Synchronization con t 2 In addition to a lock every object has a single condition variable associated with it Goals for Today Tips for Programming in a Project Team Language Support for Synchronization Discussion of Deadlocks How to wait inside a synchronization method of block void wait long timeout Wait for timeout void wait long timeout int nanoseconds variant void wait Conditions for its occurrence Solutions for breaking and avoiding deadlock How to signal in a synchronized method or block void notify wakes up oldest waiter void notifyAll like broadcast wakes everyone Condition variables can wait for a bounded length of time This is useful for handling exception cases t1 time now while ATMRequest wait CHECKPERIOD t2 time new if t2 t1 LONG TIME checkMachine Note Some slides and or pictures in the following are adapted from slides 2005 Silberschatz Galvin and Gagne Gagne Many slides generated from lecture notes by Kubiatowicz Not all Java VMs equivalent Different scheduling policies not necessarily preemptive 2 16 10 CS162 UCB Fall 2010 2 16 10 Lec 9 9 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 This is why we bug you about starting the project early It s very hard to make software project teams work correctly Can a project be efficiently partitioned Doesn t seem to be as true of big construction projects 2 16 10 Partitionable task decreases in time as you add people But if you require communication Empire state building finished in one year staging iron production thousands of miles away Or the Hoover dam built towns to hold workers CS162 UCB Fall 2010 Lec 9 10 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 CS162 UCB Fall 2010 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 2 16 10 Lec 9 11 Page 3 CS162 UCB Fall 2010 Lec 9 12 Techniques for Partitioning Tasks Communication Functional 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 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 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 Task Person A designs


View Full Document

Berkeley COMPSCI 162 - Lecture 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock

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 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock 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 9 Tips for Working in a Project Team/ Cooperating Processes and Deadlock 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?