CS444/CS544 Operating Systems Synchronization 2/14/2007 Prof. Searleman

CS444/CS544 Spring 2007 Synchronization Locks and building locks from HW primitives Reading assignment: Chapter 6 Exam#1Exam#1: Thurs. Feb. 15 th, 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