Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "CS444/CS544 Operating Systems Synchronization 2/14/2007 Prof. Searleman"— Presentation transcript:

1 CS444/CS544 Operating Systems Synchronization 2/14/2007 Prof. Searleman jets@clarkson.edu

2 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

3 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

4 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

5 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

6 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

7 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


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

Similar presentations


Ads by Google