70 likes | 170 Views
CS444/CS544 Operating Systems. Synchronization 2/14/2007 Prof. Searleman jets@clarkson.edu. CS444/CS544 Spring 2007. Synchronization Locks and building locks from HW primitives Reading assignment: Chapter 6 Exam#1 : Thurs. Feb. 15 th , 7:00 pm, Snell 213
E N D
CS444/CS544Operating Systems Synchronization 2/14/2007 Prof. Searleman jets@clarkson.edu
CS444/CS544 Spring 2007 • Synchronization • Locks and building locks from HW primitives Reading assignment: • Chapter 6 Exam#1: Thurs. Feb. 15th, 7:00 pm, Snell 213 NOTE: there is class on Friday, 2/16 (using Monday’s schedule); no LAB
Recap: Correctness • Two concurrent processes/threads must be able to execute correctly with *any* interleaving of their instructions • Scheduling is not under the control of the application writer • Note: instructions != line of code in high level programming language • If two processes/threads are operating on completely independent data, then no problem • If they share data, then application programmer may need to introduce synchronization primitives to safely coordinate their access to the shared data/resources • If shared data/resources are read only, then also no problem
Recap: Race condition • When the correct output depends on the scheduling or relative timings of operations, you call that a race condition. • Output is non-deterministic • To prevent this we need mechanisms for controlling access to shared resources • Enforce determinism
Critical Section Problem do { ENTRY_SECTION critical section /* access shared data */ EXIT_SECTION remainder section /* safe */ } • Model processes/threads as alternating between code that accesses shared data (critical section) and code that does not (remainder section) • ENTRY_SECTION requests access to shared data ; EXIT_SECTION notifies of completion of critical section
Criteria for a Good Solution to the Critical Section Problem • Mutual Exclusion • Only one process is allowed to be in its critical section at once • All other processes forced to wait on entry • When one process leaves, another may enter • Progress • If process is in the critical section, it should not be able to stop another process from entering it indefinitely • Decision of who will be next can’t be delayed indefinitely • Can’t just give one process access; can’t deny access to everyone • Bounded Waiting • After a process has made a request to enter its critical section, there should be a bound on the number of times other processes can enter their critical sections
Algorithms: • Nice progression of algorithms that violate one of these criteria and then finally get it right in previous versions of Silberschatz • Two process solutions • Generalize to multiple process solutions • Then expand on mutual exclusion See examples done in class