1 / 7

CS444/CS544 Operating Systems

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

mackenzie-payne
Download Presentation

CS444/CS544 Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS444/CS544Operating 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#1: Thurs. Feb. 15th, 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

More Related