Lecture 15: Dining Philosophers Problem

Slides:



Advertisements
Similar presentations
1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Advertisements

Operating Systems Mehdi Naghavi Winter 1385.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Cpr E 308 Spring 2004 Recap for Midterm Introductory Material What belongs in the OS, what doesn’t? Basic Understanding of Hardware, Memory Hierarchy.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Feb 8, 2005 Objectives Understand.
Computer Science 162 Discussion Section Week 3. Agenda Project 1 released! Locks, Semaphores, and condition variables Producer-consumer – Example (locks,
Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail,
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 2 (19/01/2006) Instructor: Haifeng YU.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Classical problems.
6.3 Peterson’s Solution The two processes share two variables: Int turn; Boolean flag[2] The variable turn indicates whose turn it is to enter the critical.
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.
Cpr E 308 Spring 2004 Real-time Scheduling Provide time guarantees Upper bound on response times –Programmer’s job! –Every level of the system Soft versus.
4061 Session 21 (4/3). Today Thread Synchronization –Condition Variables –Monitors –Read-Write Locks.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
Chapter 6: Process Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Background The.
Operating Systems Inter-Process Communications. Lunch time in the Philosophy Department. Dining Philosophers Problem (1)
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
CSC 360 Instructor: Kui Wu More on Process Synchronization Semaphore, Monitor, Condition Variables.
PThread Synchronization. Thread Mechanisms Birrell identifies four mechanisms commonly used in threading systems –Thread creation –Mutual exclusion (mutex)
CS 360 pthreads Condition Variables for threads. Page 2 CS 360, WSU Vancouver What is the issue? Creating a thread to perform a task and then joining.
Dining Philosophers & Monitors Questions answered in this lecture: How to synchronize dining philosophers? What are monitors and condition variables? What.
1 Processes and Threads Part II Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Deadlock and Starvation
Interprocess Communication Race Conditions
Dining Philosophers Five philosophers sit around a table
Chapter 6: Process Synchronization
Process Synchronization
Chapter 5: Process Synchronization – Part 3
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
Process Synchronization
Chapter 5: Process Synchronization – Part II
Chapter 5: Process Synchronization
Deadlock and Starvation
Lecture 12: Peterson’s Solution and Hardware Support
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
Lecture 16: Readers-Writers Problem and Message Passing
MODERN OPERATING SYSTEMS Third Edition ANDREW S
Chapter 5: Process Synchronization (Con’t)
Lecture 15: Dining Philosophers Problem
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 25 Syed Mansoor Sarwar
Process Synchronization
Module 7a: Classic Synchronization
CMPT 300: Operating Systems I
Pthread Prof. Ikjun Yeom TA – Mugyo
Chapter 7: Synchronization Examples
Review: Readers-Writers Problem
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 12: Peterson’s Solution and Hardware Support
Lecture 16: Readers-Writers Problem and Message Passing
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
Chapter 7: Synchronization Examples
CSCI1600: Embedded and Real Time Software
Lecture 20: Synchronization
Process/Thread Synchronization (Part 2)
CSE 542: Operating Systems
CSE 542: Operating Systems
Presentation transcript:

Lecture 15: Dining Philosophers Problem

Review: Mutual Exclusion Solutions Software solution Disabling interrupts Strict alternation Peterson’s solution Hardware solution TSL/XCHG Semaphore Conditional variables POSIX standards

Review: Pthreads APIs for condition variables

Review: Using condition variables int thread1_done = 0; pthread_cond_t cv; pthread_mutex_t mutex; Thread 1: printf(“hello “); pthread_mutex_lock(&mutex); thread1_done = 1; pthread_cond_signal(&cv); pthread_mutex_unlock(&mutex); Thread 2: pthread_mutex_lock(&mutex); while (thread1_done == 0) { pthread_cond_wait(&cv, &mutex); } printf(“ world\n“); pthread_mutex_unlock(&mutex);

Review: Deadlock thread a thread b proc1( ) { pthread_mutex_lock(&m1); /* use object 1 */ pthread_mutex_lock(&m2); /* use objects 1 and 2 */ pthread_mutex_unlock(&m2); pthread_mutex_unlock(&m1); } proc2( ) { pthread_mutex_lock(&m2); /* use object 2 */ pthread_mutex_lock(&m1); /* use objects 1 and 2 */ pthread_mutex_unlock(&m1); pthread_mutex_unlock(&m2); } In this example our threads are using two mutexes to control access to two different objects. Thread 1, executing proc1, first takes mutex 1, then, while still holding mutex 1, obtains mutex 2. Thread 2, executing proc2, first takes mutex 2, then, while still holding mutex 2, obtains mutex 1. However, things do not always work out as planned. If thread 1 obtains mutex 1 and, at about the same time, thread 2 obtains mutex 2, then if thread 1 attempts to take mutex 2 and thread 2 attempts to take mutex 1, we have a deadlock. thread a thread b

In this lecture Dining Philosophers Problem Readers-Writers Problem

Dining Philosophers Classic Synchronization Problem Philosopher eat, think …….. Philosopher = Process Eating needs two resources (chopsticks)

Problem: need two chopsticks to eat

First Pass at a Solution One Mutex for each chopstick Philosopher i: while (1) { Think(); lock(Left_Chopstick); lock(Right_Chopstick); Eat(); unlock(Left_Chopstick); unlock(Right_Chopstick); }

DEADLOCK

One Possible Solution Use a mutex for the whole dinner-table Philosopher i: lock(table); Eat(); Unlock(table); Performance problem!

Another Solution Problem: starvation if unfavorable scheduling! Philosopher i: Think(); unsuccessful = 1; while (unsuccessful) { lock(left_chopstick); if (try_lock(right_chopstick)) /* try_lock returns immediately if unable to grab the lock */ unsuccessful = 0; else unlock(left_chopstick); } Eat(); unlock(right_chopstick); Problem: starvation if unfavorable scheduling!

In Practice Starvation will probably not occur We can ensure this by adding randomization to the system: Add a random delay before retrying Unlikely that our random delays will be in sync too many times

Solution with Random Delays Philosopher i: Think(); while (unsuccessful) { wait(random()); lock(left_chopstick); if (trylock(right_chopstick)) unsuccessful = 0; else unlock(left_chopstick); } Eat(); unlock(right_chopstick);

Solution without random delay Do not try to take forks one after another Don’t have each fork protected by a different mutex Try to grab both forks at the same time