1 Outline for Today Objective: –5 Dining Philosophers –Reader-writer problem –Message Passing Administrative details: –Check for demo location with grader.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Operating Systems: Monitors 1 Monitors (C.A.R. Hoare) higher level construct than semaphores a package of grouped procedures, variables and data i.e. object.
1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
Ch 7 B.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 6 Concurrency: Deadlock and Starvation
Chapter 6 Concurrency: Deadlock and Starvation
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Classical Problems of Concurrency
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Synchronization CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
Concurrency: Deadlock and Starvation Chapter 6. Revision Describe three necessary conditions for deadlock Which condition is the result of the three necessary.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
IPC and Classical Synchronization Problems
1 Concurrency: Deadlock and Starvation Chapter 6.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Condition Variables Revisited Copyright ©: University of Illinois CS 241 Staff1.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Concurrency: Deadlock and Starvation Chapter 6. Goal and approach Deadlock and starvation Underlying principles Solutions? –Prevention –Detection –Avoidance.
1 Concurrency: Deadlock and Starvation Chapter 6.
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago Polytechnic,
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 2 (19/01/2006) Instructor: Haifeng YU.
1 Processes Chapter Processes 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Classical problems.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Operating Systems CMPSC 473 Mutual Exclusion Lecture 14: October 14, 2010 Instructor: Bhuvan Urgaonkar.
4061 Session 21 (4/3). Today Thread Synchronization –Condition Variables –Monitors –Read-Write Locks.
Chap 6 Synchronization. Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Solutions to Second 4330/6310 Quiz Spring First question Which of the following statements are true or false (2 points) and why? (3 points)
1 Outline Objective: –Message Passing Administrative details: –Sign up for demo slots on Demo Scheduler –Check for demo location with grader –Submit details.
1 Outline Part 1 Objectives: –To define the process and thread abstractions. –To briefly introduce mechanisms for implementing processes (threads). –To.
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
Problems with Semaphores Used for 2 independent purposes –Mutual exclusion –Condition synchronization Hard to get right –Small mistake easily leads to.
CS533 – Spring Jeanie M. Schwenk Experiences and Processes and Monitors with Mesa What is Mesa? “Mesa is a strongly typed, block structured programming.
Concurrency in Shared Memory Systems Synchronization and Mutual Exclusion.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Processes and Threads Part II Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Homework-6 Questions : 2,10,15,22.
1 Outline for Today Objectives: –To define the process and thread abstractions. –To briefly introduce mechanisms for implementing processes (threads).
1 Outline for Today Objectives: –Discuss “Classic” concurrency problems Administrative details: –Schedule on webpage now includes readings from Tanenbaum.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Interprocess Communication Race Conditions
Outline Objective: Administrative details: Message Passing
Concurrency: Mutual Exclusion and Synchronization
“Language Mechanism for Synchronization”
Classical Synchronization Problems
Outline for Today Objective: Administrative details:
2-Dining Puppies Mutex Failure.
Concurrency: Mutual Exclusion and Synchronization
Semaphore Originally called P() and V() wait (S) { while S <= 0
Module 7a: Classic Synchronization
CSE 451 Section 1/27/2000.
Process/Thread Synchronization (Part 2)
CSE 542: Operating Systems
CSE 542: Operating Systems
Presentation transcript:

1 Outline for Today Objective: –5 Dining Philosophers –Reader-writer problem –Message Passing Administrative details: –Check for demo location with grader TA’s and me: come to our offices UTA’s if they don’t post to newsgroup, ask.

2 5 Dining Philosophers Philosopher 0 Philosopher 1 Philosopher 2 Philosopher 3 Philosopher 4 while(food available) {pick up 2 adj. forks; eat; put down forks; think awhile; }

3 Template for Philosopher while (food available) { /*pick up forks*/ eat; /*put down forks*/ think awhile; }

4 Naive Solution while (food available) { /*pick up forks*/ eat; /*put down forks*/ think awhile; } P(fork[left(me)]); P(fork[right(me)]); V(fork[left(me)]); V(fork[right(me)]); Does this work?

5 Simplest Example of Deadlock Thread 0 P(R1) P(R2) V(R1) V(R2) Thread 1 P(R2) P(R1) V(R2) V(R1) Interleaving P(R1) P(R2) P(R1) waits P(R2) waits R1 and R2 initially 1 (binary semaphore)

6 Conditions for Deadlock Mutually exclusive use of resources –Binary semaphores R1 and R2 Circular waiting –Thread 0 waits for Thread 1 to V(R2) and Thread 1 waits for Thread 0 to V(R1) Hold and wait –Holding either R1 or R2 while waiting on other No pre-emption –Neither R1 nor R2 are removed from their respective holding Threads.

7 Philosophy 101 (or why 5DP is interesting) How to eat with your Fellows without causing Deadlock. –Circular arguments (the circular wait condition) –Not giving up on firmly held things (no preemption) –Infinite patience with Half-baked schemes ( hold some & wait for more) Why Starvation exists and what we can do about it.

8 Dealing with Deadlock It can be prevented by breaking one of the prerequisite conditions: Mutually exclusive use of resources –Example: Allowing shared access to read-only files (readers/writers problem) circular waiting –Example: Define an ordering on resources and acquire them in order hold and wait no pre-emption

9 while (food available) { if (me  0) {P(fork[left(me)]); P(fork[right(me)]);} else {(P(fork[right(me)]); P(fork[left(me)]); } eat; V(fork[left(me)]); V(fork[right(me)]); think awhile; } Circular Wait Condition

10 Hold and Wait Condition while (food available) {P(mutex); while (forks [me] != 2) {blocking[me] = true; V(mutex); P(sleepy[me]); P(mutex);} forks [leftneighbor(me)] --; forks [rightneighbor(me)]--; V(mutex): eat; P(mutex); forks [leftneighbor(me)] ++; forks [rightneighbor(me)]++; if (blocking[leftneighbor(me)]) {blocking [leftneighbor(me)] = false; V(sleepy[leftneighbor(me)]); } if (blocking[rightneighbor(me)]) {blocking[rightneighbor(me)] = false; V(sleepy[rightneighbor(me)]); } V(mutex); think awhile; }

11 Starvation The difference between deadlock and starvation is subtle: –Once a set of processes are deadlocked, there is no future execution sequence that can get them out of it. –In starvation, there does exist some execution sequence that is favorable to the starving process although there is no guarantee it will ever occur. –Rollback and Retry solutions are prone to starvation. –Continuous arrival of higher priority processes is another common starvation situation.

12 5DP - Monitor Style Boolean eating [5]; Lock forkMutex; Condition forksAvail; void PickupForks (int i) { forkMutex.Acquire( ); while ( eating[(i-1)%5]  eating[(i+1)%5] ) forksAvail.Wait(&forkMutex); eating[i] = true; forkMutex.Release( ); } void PutdownForks (int i) { forkMutex.Acquire( ); eating[i] = false; forksAvail.Broadcast(&forkMute x); forkMutex.Release( ); }

13 What about this? while (food available) {forkMutex.Acquire( ); while (forks [me] != 2) {blocking[me]=true; forkMutex.Release( ); sleep( ); forkMutex.Acquire( );} forks [leftneighbor(me)]--; forks [rightneighbor(me)]--; forkMutex.Release( ): eat; forkMutex.Acquire( ); forks[leftneighbor(me)] ++; forks [rightneighbor(me)]++; if (blocking[leftneighbor(me)] || blocking[rightneighbor(me)]) wakeup ( ); forkMutex.Release( ); think awhile; }

14 Readers/Writers Problem Synchronizing access to a file or data record in a database such that any number of threads requesting read-only access are allowed but only one thread requesting write access is allowed, excluding all readers.

15 Template for Readers/Writers Reader() {while (true) { read } Writer() {while (true) { write } /*request r access*/ /*release r access*/ /*request w access*/ /*release w access*/

16 Template for Readers/Writers Reader() {while (true) { read } Writer() {while (true) { write } fd = open(foo, 0); close(fd); fd = open(foo, 1); close(fd);

17 Template for Readers/Writers Reader() {while (true) { read } Writer() {while (true) { write } startRead(); endRead(); startWrite(); endWrite();

18 R/W - Monitor Style Boolean busy = false; int numReaders = 0; Lock filesMutex; Condition OKtoWrite, OKtoRead; void startRead () { filesMutex.Acquire( ); while ( busy ) OKtoRead.Wait(&filesMutex); numReaders++; filesMutex.Release( );} void endRead () { filesMutex.Acquire( ); numReaders--; if (numReaders == 0) OKtoWrite.Signal(&filesMutex); filesMutex.Release( );} void startWrite() { filesMutex.Acquire( ); while (busy || numReaders != 0) OKtoWrite.Wait(&filesMutex); busy = true; filesMutex.Release( );} void endWrite() { filesMutex.Acquire( ); busy = false; OKtoRead.Broadcast(&filesMutex); OKtoWrite.Signal(&filesMutex); filesMutex.Release( );}

19 Guidelines for Choosing Lock Granularity 1. Keep critical sections short. Push “noncritical” statements outside of critical sections to reduce contention. 2. Limit lock overhead. Keep to a minimum the number of times mutexes are acquired and released. Note tradeoff between contention and lock overhead. 3. Use as few mutexes as possible, but no fewer. Choose lock scope carefully: if the operations on two different data structures can be separated, it may be more efficient to synchronize those structures with separate locks. Add new locks only as needed to reduce contention. “Correctness first, performance second!”

20 Semaphore Solution int readCount = 0; semaphore mutex = 1; semaphore writeBlock = 1;

21 Reader(){ while (TRUE) { other stuff; P(mutex); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex); access resource; P(mutex); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex); }} Writer(){ while(TRUE){ other stuff; P(writeBlock); access resource; V(writeBlock); }}

22 Attempt at Writer Priority int readCount = 0, writeCount = 0; semaphore mutex1 = 1, mutex2 = 1; semaphore readBlock = 1; semaphore writeBlock = 1;

23 Reader(){ while (TRUE) { other stuff; P(readBlock); P(mutex1); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); access resource; P(mutex1); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex1); }} Writer(){ while(TRUE){ other stuff; P(mutex2); writeCount = writeCount +1; if (writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access resource; V(writeBlock); P(mutex2); writeCount - writeCount - 1; if (writeCount == 0) V(readBlock); V(mutex2); }} Reader2Writer1Reader1

24 Reader(){ while (TRUE) { other stuff; P(readBlock); P(mutex1); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); access resource; P(mutex1); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex1); }} Writer(){ while(TRUE){ other stuff; P(mutex2); writeCount = writeCount +1; if (writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access resource; V(writeBlock); P(mutex2); writeCount - writeCount - 1; if (writeCount == 0) V(readBlock); V(mutex2); }} Reader2Writer1Reader1

25 Reader(){ while (TRUE) { other stuff; P(writePending); P(readBlock); P(mutex1); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); V(writePending); access resource; P(mutex1); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex1); }} Writer(){ while(TRUE){ other stuff; P(mutex2); writeCount = writeCount +1; if (writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access resource; V(writeBlock); P(mutex2); writeCount - writeCount - 1; if (writeCount == 0) V(readBlock); V(mutex2); }}

26 Reader(){ while (TRUE) { other stuff; P(writePending); P(readBlock); P(mutex1); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); V(writePending); access resource; P(mutex1); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex1); }} Writer(){ while(TRUE){ other stuff; P(mutex2); writeCount = writeCount +1; if (writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access resource; V(writeBlock); P(mutex2); writeCount - writeCount - 1; if (writeCount == 0) V(readBlock); V(mutex2); }} Reader1Writer1Reader2 Assumptions about semaphore semantics?

27 Reader(){ while (TRUE) { other stuff; P(writePending); P(readBlock); P(mutex1); readCount = readCount +1; if(readCount == 1) P(writeBlock); V(mutex1); V(readBlock); V(writePending); access resource; P(mutex1); readCount = readCount -1; if(readCount == 0) V(writeBlock); V(mutex1); }} Writer(){ while(TRUE){ other stuff; P(mutex2); writeCount = writeCount +1; if (writeCount == 1) P(readBlock); V(mutex2); P(writeBlock); access resource; V(writeBlock); P(mutex2); writeCount - writeCount - 1; if (writeCount == 0) V(readBlock); V(mutex2); }} Assume the writePending semaphore was omitted. What would happen? Reader1Writer1Reader2

28 Assume the writePending semaphore was omitted in the solution just given. What would happen? This is supposed to give writers priority. However, consider the following sequence: Reader 1 arrives, executes thro’ P(readBlock); Reader 1 executes P(mutex1); Writer 1 arrives, waits at P(readBlock); Reader 2 arrives, waits at P(readBlock); Reader 1 executes V(mutex1); then V(readBlock); Reader 2 may now proceed…wrong

29 Interprocess Communication - Messages Assume no explicit sharing of data elements in the address spaces of processes wishing to cooperate/communicate. Essence of message-passing is copying (although implementations may avoid actual copies whenever possible). Problem-solving with messages - has a feel of more active involvement by participants.

30 Issues System calls for sending and receiving messages with the OS(s) acting as courier. –Variations on exact semantics of primitives and in the definition of what comprises a message. Naming - direct (to/from pids), indirect (to distinct objects - e.g., mailboxes, ports, sockets) –How do unrelated processes “find” each other? Buffering - capacity and blocking semantics. Guarantees - in-order delivery? no lost messages?

31 Send and Receive

32 5 DP – Direct Send/Receive Message Passing Between Philosophers Philosopher 0 (thinking) Philosopher 1 Philosopher 2 Philosopher 3 (eating) Philosopher 4 Fork please?

33 Philosopher 0 (thinking) Philosopher 1 Philosopher 2 Philosopher 3 (eating) Philosopher 4 Umm. Oh yeah.

34 Philosopher 0 (thinking) Philosopher 1 Philosopher 2 Philosopher 3 (eating) Philosopher 4 Fork please?

35 Philosopher 0 (thinking) Philosopher 1 Philosopher 2 Philosopher 3 (eating) Philosopher 4 Fork please? I’ll ignore that request until I’m done

36 Philosopher 0 (thinking) Philosopher 1 Philosopher 2 Philosopher 3 (eating) Philosopher 4 Fork please?

37 Client / Server server-> Start here

38 Example: Time Service

39 Example: Time Service via Messages

40 Client / Server with Threads

41 Hiding Message-Passing: RPC

42 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); P1P1 Receive

43 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); please do foo for P 0 with param P1P1 Receive blocked here

44 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); please do foo for P 0 with param P1P1 Receive r = foo(param); // actual call blocked here

45 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); P1P1 Receive r = foo(param); // actual call Reply returning r to P 0 blocked here

46 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); P1P1 Receive r = foo(param); // actual call Reply returning r to P 0

47 Remote Procedure Call - RPC Looks like a nice familiar procedure call P0P0 result = foo(param); P1P1 Receive r = foo(param); // actual call Reply

48 5DP via RPC with Fork Manager Looks like a nice familiar procedure call Philosopher 0 result = PickupForks (0); Fork Server Receive r = proc(param); // explicit queuing when necessary Reply

49 Example: Time Service via RPC

50 What’s Really Going On

51 RPC Issues