The dining philosophers problem. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 13
|
|
- Clementine Reed
- 6 years ago
- Views:
Transcription
1 CS 361 Concurrent programming Drexel University Fall 2004 Lecture 13 Bruce Cha and Vera Zaychikr. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce these notes for their own use. The dining philosophers problem The dining philosophers problem involves five philosophers sitting at a round table with five forks interleaved between them. A bowl of spaghetti sits in the center of the table. Philosophers think for a while, become hungry, and try to eat. After eating for a while, a philosopher is ready to think again and the cycle repeats. A philosopher needs both forks to eat, the one on its right and the on its left. Sometimes the problem is presented with chopsticks instead of forks to emphasize that a philosopher needs both at the same time to eat. Only one philosopher can use a fork at a time. page 1 page 2 Constraints on the dining philosophers Avoid: deadlock (each philosopher holding a fork and refusing to relinquish it). Also, starvation (literally). Also, favoritism. Desirable goal: attain maximal parallelism (a hungry philosopher eats if its forks are not being used by other philosophers to eat). Although it looks contrived, it exemplifies a typical kind of synchronization problem, where there are overlapping sets of resources whose use must be coordinated. Dining philosophers: one solution using semaphores Central server object that records states of philosophers. Avoids deadlock/livelock, but doesn t address the issue of starvation by a philosopher page 3 page 4 page 5 Approach taken by solution A philosopher thinks for a random period of time, then becomes hungry. The philosopher then asks the central server for its forks. The central server checks the availability of the forks by examining the states of the hungry philosopher s two neighbors. If neither neighbor is eating, the hungry philosopher eats. Otherwise he waits, through P(self[i]). (One semaphore per philosopher.) page 6 Solution, cont. Once a philosopher obtains its two forks, it eats for a random amount of time, put down the forks, and then repeats the cycle. When a philosopher puts down his forks, the central server checks the philosopher s two neighbors with calls to the test method to see if either is hungry. If either is hungry and its two forks are available, the neighbor is unblocked with V(self[k]).
2 Dining philosophers server class DiningServer extends MyObject { private static final int // States THINKING = 0, HUNGRY = 1, EATING = 2; private int numphils = 0; private int[] state = null; private BinarySemaphore[] self = null; // array of sem. private BinarySemaphore mutex = null; public DiningServer(int numphils) { super("diningserver for " + numphils + " philosophers"); this.numphils = numphils; state = new int[numphils]; for (int i = 0; i < numphils; i++) state[i] = THINKING; self = new BinarySemaphore[numPhils]; for (int i = 0; i < numphils; i++) self[i] = new BinarySemaphore(0); mutex = new BinarySemaphore(1); page 7 Dining philosophers server, cont. private final int left(int i) { return (numphils + i - 1) % numphils; // wraparound indexing private final int right(int i) { return (i + 1) % numphils; public void takeforks(int i) { // when want to eat test(i); // will do a V(self[i]) if okay to eat P(self[i]); public void putforks(int i) { // when done eating state[i] = THINKING; test(left(i)); // may do release -- V -- for left test(right(i)); // may do V for right page 8 Dining philosophers server, cont. private void test(int k) { if (state[left(k)]!= EATING && state[right(k)]!= EATING && state[k] == HUNGRY) { state[k] = EATING; V(self[k]); page 9 Dining philosophers sample output /*... Example compile and run(s) age()=3960, Philosopher 0 is eating for 247 ms age()=4120, Philosopher 1 wants to eat D:\>javac dphi.java dpdr.java age()=4180, Philosopher 0 is thinking for 1642 ms age()=4180, Philosopher 1 is eating for 787 ms D:\>java DiningPhilosophers -R age()=5000, Philosopher 1 is thinking for 2828 ms DiningPhilosophers: numphilosophers=5, runtime=10 age()=5170, Philosopher 3 wants to eat Philosopher 0 is alive, napthink=4000, napeat=1000 age()=5170, Philosopher 3 is eating for 559 ms Philosopher 1 is alive, napthink=4000, napeat=1000 age()=5440, Philosopher 4 wants to eat Philosopher 2 is alive, napthink=4000, napeat=1000 age()=5720, Philosopher 3 is thinking for 319 ms Philosopher 3 is alive, napthink=4000, napeat=1000 age()=5720, Philosopher 4 is eating for 850 ms Philosopher 4 is alive, napthink=4000, napeat=1000 age()=5830, Philosopher 0 wants to eat All Philosopher threads started age()=6050, Philosopher 3 wants to eat age()=110, Philosopher 0 is thinking for 3816 ms age()=6270, Philosopher 2 wants to eat age()=110, Philosopher 1 is thinking for 2079 ms age()=6270, Philosopher 2 is eating for 33 ms age()=110, Philosopher 2 is thinking for 2646 ms age()=6320, Philosopher 2 is thinking for 92 ms age()=170, Philosopher 3 is thinking for 560 ms age()=6430, Philosopher 2 wants to eat age()=170, Philosopher 4 is thinking for 761 ms age()=6430, Philosopher 2 is eating for 612 ms age()=720, Philosopher 3 wants to eat age()=6600, Philosopher 4 is thinking for 3242 ms age()=720, Philosopher 3 is eating for 717 ms age()=6600, Philosopher 0 is eating for 320 ms age()=940, Philosopher 4 wants to eat age()=6930, Philosopher 0 is thinking for 3193 ms age()=1430, Philosopher 3 is thinking for 1653 ms age()=7040, Philosopher 2 is thinking for 3221 ms age()=1430, Philosopher 4 is eating for 913 ms age()=7040, Philosopher 3 is eating for 142 ms age()=2200, Philosopher 1 wants to eat age()=7200, Philosopher 3 is thinking for 2902 ms age()=2200, Philosopher 1 is eating for 86 ms age()=7800, Philosopher 1 wants to eat age()=2310, Philosopher 1 is thinking for 1797 ms age()=7800, Philosopher 1 is eating for 553 ms age()=2370, Philosopher 4 is thinking for 3052 ms age()=8410, Philosopher 1 is thinking for 3382 ms age()=2810, Philosopher 2 wants to eat age()=9840, Philosopher 4 wants to eat age()=2810, Philosopher 2 is eating for 442 ms age()=9840, Philosopher 4 is eating for 678 ms age()=3140, Philosopher 3 wants to eat age()=10110, Philosopher 3 wants to eat age()=3300, Philosopher 2 is thinking for 3003 ms age()=10110, Philosopher 0 wants to eat age()=3300, Philosopher 3 is eating for 465 ms age()=10110, time to stop the Philosophers and exit age()=3740, Philosopher 3 is thinking for 1381 ms... end of example run(s) */ age()=3960, Philosopher 0 wants to eat page 10 Philosopher class Philosopher class, con t private void think() { int napping; napping = 1 + (int) random(napthink); System.out.println("age()=" + age() + ", " + getname() class Philosopher extends MyObject implements Runnable { + " is thinking for " + napping + " ms"); private int id = 0; nap(napping); private int napthink = 0; // both are in private int napeat = 0; // milliseconds private DiningServer ds = null; private void eat() { public Philosopher(String name, int id, int napthink, int napping; int napeat, DiningServer ds) { napping = 1 + (int) random(napeat); super(name + " " + id); System.out.println("age()=" + age() + ", " + this.id = id; getname() this.napthink = napthink; + " is eating for " + napping + " ms"); this.napeat = napeat; this.ds = ds; nap(napping); System.out.println(getName() + " is alive, napthink=" + napthink + ", napeat=" + napeat); new Thread(this).start(); // self-starting object page 11 page 12
3 page 13 Philosopher class cont. public void run() { while (true) { think(); // Life is thinking System.out.println("age()=" + age() + ", " + getname() + " wants to eat"); ds.takeforks(id); eat(); // and eating ds.putforks(id); D.P. driver (main) class DiningPhilosophers extends MyObject { public static void main(string[] args) { // parse command line options, if any, to override defaults GetOpt go = new GetOpt(args, "Up:R:"); go.opterr = true; String usage = "Usage: -p numphilosophers" + " -R runtime napthink[i] napeat[i] i=0,1,..."; int ch = -1; int numphilosophers = 5; int runtime = 60; // seconds while ((ch = go.getopt())!= go.opteof) { if ((char)ch == 'U') { System.out.println(usage); System.exit(0); else if ((char)ch == 'p') numphilosophers = go.processarg(go.optargget(), numphilosophers); else if ((char)ch == 'R') runtime = go.processarg(go.optargget(), runtime); else { System.err.println(usage); System.exit(1); System.out.println("DiningPhilosophers: numphilosophers=" + numphilosophers + ", runtime=" + runtime); // process non-option command line arguments int[] napthink = new int[numphilosophers]; int[] napeat = new int[numphilosophers]; for (int i = 0; i < numphilosophers; i++) { napthink[i] = 8; napeat[i] = 2; // defaults int argnum = go.optindexget(); for (int i = 0; i < numphilosophers; i++) { napthink[i] = go.tryarg(argnum++, napthink[i]); napeat[i] = go.tryarg(argnum++, napeat[i]); page 14 page 15 D.P. driver cont. // create the DiningServer object DiningServer ds = new DiningServer(numPhilosophers); // create the Philosophers (they have self-starting // threads) for (int i = 0; i < numphilosophers; i++) new Philosopher("Philosopher", i, napthink[i]*1000, napeat[i]*1000, ds); System.out.println("All Philosopher threads started"); // let the Philosophers run for a while nap(runtime*1000); System.out.println("age()=" + age() + ", time to stop the Philosophers and exit"); System.exit(0); page 16 Avoiding deadlock Another way to avoid deadlock is to make sure that at most NUMPHILS-1 philosophers are given permission to pick up a fork. That ensures that one of them will always be able to pick up two forks. Avoiding deadlock class DiningServer extends MyObject { private static final int THINKING = 0, HUNGRY = 1, EATING = 2; private int numphils = 0; private int[] state = null; private BinarySemaphore[] fork = null; private CountingSemaphore room = null; public DiningServer(int numphils) { super("diningserver for " + numphils + " philosophers"); this.numphils = numphils; state = new int[numphils]; for (int i = 0; i < numphils; i++) state[i] = THINKING; fork = new BinarySemaphore[numPhils]; for (int i = 0; i < numphils; i++) fork[i] = new BinarySemaphore(1); room = new CountingSemaphore(numPhils-1); System.out.println("Dining room limited to " + (numphils- 1)); page 17 page 18 The takeforks code private final int left(int i) { return (numphils + i - 1) % numphils; private final int right(int i) { return (i + 1) % numphils; public void takeforks(int i) { P(room); P(fork[i]); P(fork[right(i)]); // since the counting semaphore room is set to numphils-1, one // philosopher is excluded from trying to pick up a fork if // all should try at the same // time. state[i] = EATING; public void putforks(int i) { V(fork[i]); V(fork[right(i)]); V(room); state[i] = THINKING;
4 Notes on Stalling s solution Prevents starvation because a philosopher picks up a left fork and doesn t put it down until it eats. Prevents deadlock because only N-1 philosophers are allowed to pick up forks (the use of the room counting semaphore), which prevents deadlock. Maximal parallelism The problem with Stalling s solution is that it doesn t allow maximal parallelism one person is eating, the rest are all blocked waiting for their other fork. Increased parallelism if every other philosopher eating instead of just one. There s another solution where one philosopher is designated as odd and picks up the forks in reverse order from the others. Then deadlock cannot occur but again maximal parallelism isn t achieved. page 19 page 20 Another non-maximal solution public void takeforks(int i) { if (i > 0) { P(fork[i]); P(fork[right(i)]); else { P(fork[right(i)]); P(fork[i]); state[i] = EATING; Avoiding starvation This solution avoids deadlock but doesn t guarantee that no philosopher will starve. Odd philosopher out takes the fork in his/her other hand. Still doesn t achieve maximal parallelism. page 21 page 22 Exercise: avoid starvation Modify the program so that it is starvation-free. One way to do this is to add another state starving and not let a hungry philosopher eat if it has a starving neighbor. A hungry philosopher enters this state if its neighbors have put down their forks and the philosopher under consideration has not been able to eat. Exercise: avoid starvation You must change the state of a philosopher only when one of its neighbors puts down its forks. Don t make a philosopher starve the first time it tries to pick up its forks and it can t. Can t have two neighboring philosophers starving at the same time because either they will deadlock or you will still have starvation. page 23 page 24
5 Exercise: avoid starvation (alternatives) Or you can count the number of times it has not been able to pick up its forks, or base it on how many times each fork has been picked up. Or assign ticket numbers like Lamport s algorithm. Database reader/writer problem The readers and writers problem: readers may read a database simultaneously as long as no writer writes Only one writer at a time may write (if there are no active readers). Attain: maximal parallelism (readers may read simultaneously if there is no writing), data integrity (only one writer at a time if no readers are reading). Possible additional goal: avoid writer starvation (locked out of writing because readers are always coming along to read). page 25 page 26 page 27 Database reader/writer solution class Database extends MyObject { private int numreaders = 0; private BinarySemaphore mutex = new BinarySemaphore(1); private BinarySemaphore ok = new BinarySemaphore(1); public Database() { super("database"); Reader code public void startread(int i) { numreaders++; if (numreaders == 1) { System.out.println("age=" + age() + " reader " + i + " waiting to read, numreaders=" + numreaders); P(ok); System.out.println(" age=" + age() + " reader " + i + " has begun reading, numreaders=" + numreaders); public void endread(int i) { numreaders--; System.out.println(" age=" + age() + " reader " + i + " finished reading, numreaders=" + numreaders); if (numreaders == 0) V(ok); page 28 Writer code Notes on reader/writer solution public void startwrite(int i) { P(ok); System.out.println(" age=" + age() + " WRITER " + i + " has begun Writing"); public void endwrite(int i) { System.out.println(" age=" + age() + " WRITER " + i + " has finished Writing"); V(ok); Only the first reader should lock the ok lock. The last reader should unlock it when it finishes its read. Then the Writers can write. Starvation of writers might occur. page 29 page 30
CS 361 Concurrent programming Drexel University Spring 2000 Lecture 14. The dining philosophers problem
CS 361 Concurrent programming Drexel University Spring 2000 Lecture 14 Bruce Char. All rights reserved by the author. Permission is given to students enrolled in CS361 Spring 2000 to reproduce these notes
More informationEI 338: Computer Systems Engineering (Operating Systems & Computer Architecture)
EI 338: Computer Systems Engineering (Operating Systems & Computer Architecture) Dept. of Computer Science & Engineering Chentao Wu wuct@cs.sjtu.edu.cn Download lectures ftp://public.sjtu.edu.cn User:
More informationSections 01 (11:30), 02 (16:00), 03 (8:30) Ashraf Aboulnaga & Borzoo Bonakdarpour
Course CS350 - Operating Systems Sections 01 (11:30), 02 (16:00), 03 (8:30) Instructor Ashraf Aboulnaga & Borzoo Bonakdarpour Date of Exam October 25, 2011 Time Period 19:00-21:00 Duration of Exam Number
More informationProcess Synchronization
Process Synchronization Part II, Modified by M.Rebaudengo - 2013 Silberschatz, Galvin and Gagne 2009 Classical Problems of Synchronization Consumer/Producer with Bounded-Buffer Problem s and s Problem
More informationReaders/Writers Problem. Readers/Writers: Scenario 1. Readers/Writers Problem. Today: Synchronization for Readers/Writers Problem
Today: Synchronization for Readers/Writers Problem An object is shared among may threads, each belonging to one of two classes: Readers: read data, never modify it Writers: read data and modify it Using
More informationRoadmap. Readers-Writers Problem. Readers-Writers Problem. Readers-Writers Problem (Cont.) Dining Philosophers Problem.
CSE 421/521 - Operating Systems Fall 2011 Lecture - X Process Synchronization & Deadlocks Roadmap Classic Problems of Synchronization Readers and Writers Problem Dining-Philosophers Problem Sleeping Barber
More informationRoadmap. Tevfik Ko!ar. CSC Operating Systems Fall Lecture - XI Deadlocks - II. Louisiana State University
CSC 4103 - Operating Systems Fall 2009 Lecture - XI Deadlocks - II Tevfik Ko!ar Louisiana State University September 29 th, 2009 1 Roadmap Classic Problems of Synchronization Bounded Buffer Readers-Writers
More informationRoadmap. Bounded-Buffer Problem. Classical Problems of Synchronization. Bounded Buffer 1 Semaphore Soln. Bounded Buffer 1 Semaphore Soln. Tevfik Ko!
CSC 4103 - Operating Systems Fall 2009 Lecture - XI Deadlocks - II Roadmap Classic Problems of Synchronization Bounded Buffer Readers-Writers Dining Philosophers Sleeping Barber Deadlock Prevention Tevfik
More information5 Classical IPC Problems
OPERATING SYSTEMS CLASSICAL IPC PROBLEMS 2 5 Classical IPC Problems The operating systems literature is full of interesting problems that have been widely discussed and analyzed using a variety of synchronization
More informationCS370 Operating Systems
CS370 Operating Systems Colorado State University Yashwant K Malaiya Fall 2017 Lecture 12 Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ 2 Mutex vs Semaphore Mutex is binary,
More informationOperating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst
Operating Systems CMPSCI 377 Spring 2017 Mark Corner University of Massachusetts Amherst Clicker Question #1 If we have 100 threads and 100 processors, how often does Hello get printed? (A) 100 times per
More informationChapter 6: Synchronization. Chapter 6: Synchronization. 6.1 Background. Part Three - Process Coordination. Consumer. Producer. 6.
Part Three - Process Coordination Chapter 6: Synchronization 6.1 Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure
More informationProcess Synchronization. studykorner.org
Process Synchronization Semaphore Implementation Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time The main disadvantage of the semaphore definition
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Chapter 6: Synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Mutex Locks 6.6 Semaphores 6.7 Classic
More informationProcess Synchronization
CS307 Process Synchronization Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2018 Background Concurrent access to shared data may result in data inconsistency
More informationSemaphores (by Dijkstra)
CSCI 4401 Principles of Operating Systems I Process Synchronization II: Classic Problems Vassil Roussev vassil@cs.uno.edu Semaphores (by Dijkstra) A higher-level way of doing synchronization between threads/processes
More informationChapter 7: Process Synchronization!
Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Monitors 7.1 Background Concurrent access to shared
More informationProcess Synchronization
TDDI04 Concurrent Programming, Operating Systems, and Real-time Operating Systems Process Synchronization [SGG7] Chapter 6 Copyright Notice: The lecture notes are mainly based on Silberschatz s, Galvin
More informationLecture 3: Intro to Concurrent Processing using Semaphores
Lecture 3: Intro to Concurrent Processing using Semaphores Semaphores; The Prucer-Consumer problem; The Dining Philosophers problem; The Readers-Writers Problem: Readers Preference Passing the Baton Ballhausen
More informationLesson 6: Process Synchronization
Lesson 6: Process Synchronization Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization
More informationProcess Synchronization
Process Synchronization Chapter 6 2015 Prof. Amr El-Kadi Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly
More informationCS370 Operating Systems
CS370 Operating Systems Colorado State University Yashwant K Malaiya Spring 1019 L12 Synchronization Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ Critical section: shared
More informationCSE 4/521 Introduction to Operating Systems
CSE 4/521 Introduction to Operating Systems Lecture 7 Process Synchronization II (Classic Problems of Synchronization, Synchronization Examples) Summer 2018 Overview Objective: 1. To examine several classical
More informationProcess Management And Synchronization
Process Management And Synchronization In a single processor multiprogramming system the processor switches between the various jobs until to finish the execution of all jobs. These jobs will share the
More informationCS370: System Architecture & Software [Fall 2014] Dept. Of Computer Science, Colorado State University
Frequently asked questions from the previous class survey CS 370: SYSTEM ARCHITECTURE & SOFTWARE [PROCESS SYNCHRONIZATION] Shrideep Pallickara Computer Science Colorado State University Semaphores From
More informationSynchronization Principles II
CSC 256/456: Operating Systems Synchronization Principles II John Criswell University of Rochester 1 Synchronization Issues Race conditions and the need for synchronization Critical Section Problem Mutual
More informationProcess Synchronization
CSC 4103 - Operating Systems Spring 2007 Lecture - VI Process Synchronization Tevfik Koşar Louisiana State University February 6 th, 2007 1 Roadmap Process Synchronization The Critical-Section Problem
More informationOperating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy
Operating Systems Designed and Presented by Dr. Ayman Elshenawy Elsefy Dept. of Systems & Computer Eng.. AL-AZHAR University Website : eaymanelshenawy.wordpress.com Email : eaymanelshenawy@yahoo.com Reference
More informationCHAPTER 6: PROCESS SYNCHRONIZATION
CHAPTER 6: PROCESS SYNCHRONIZATION The slides do not contain all the information and cannot be treated as a study material for Operating System. Please refer the text book for exams. TOPICS Background
More informationLecture Topics. Announcements. Today: Concurrency (Stallings, chapter , 5.7) Next: Exam #1. Self-Study Exercise #5. Project #3 (due 9/28)
Lecture Topics Today: Concurrency (Stallings, chapter 5.1-5.4, 5.7) Next: Exam #1 1 Announcements Self-Study Exercise #5 Project #3 (due 9/28) Project #4 (due 10/12) 2 Exam #1 Tuesday, 10/3 during lecture
More informationMidterm on next week Tuesday May 4. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 9
CS 361 Concurrent programming Drexel University Fall 2004 Lecture 9 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
More informationSynchronization Principles
Synchronization Principles Gordon College Stephen Brinton The Problem with Concurrency Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms
More informationExplain briefly how starvation may occur in process scheduling. (2 marks)
OMP25111 Lecture 8 1/40 From last time Explain briefly how starvation may occur in process scheduling. (2 marks) In round-robin scheduling, new processes are typically placed at the end of the ready-state
More informationInterprocess Communication By: Kaushik Vaghani
Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the
More informationCS 537 Lecture 8 Monitors. Thread Join with Semaphores. Dining Philosophers. Parent thread. Child thread. Michael Swift
CS 537 Lecture 8 Monitors Michael Swift Two Classes of Synchronization Problems Uniform resource usage with simple scheduling constraints No other variables needed to express relationships Use one semaphore
More informationChapter 5: Process Synchronization. Operating System Concepts Essentials 2 nd Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationIntroduction to Operating Systems
Introduction to Operating Systems Lecture 4: Process Synchronization MING GAO SE@ecnu (for course related communications) mgao@sei.ecnu.edu.cn Mar. 18, 2015 Outline 1 The synchronization problem 2 A roadmap
More informationConcept of a process
Concept of a process In the context of this course a process is a program whose execution is in progress States of a process: running, ready, blocked Submit Ready Running Completion Blocked Concurrent
More informationSynchronization. CS 475, Spring 2018 Concurrent & Distributed Systems
Synchronization CS 475, Spring 2018 Concurrent & Distributed Systems Review: Threads: Memory View code heap data files code heap data files stack stack stack stack m1 m1 a1 b1 m2 m2 a2 b2 m3 m3 a3 m4 m4
More informationChapter 5: Process Synchronization
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Operating System Concepts 9th Edition Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution
More informationChapter 5: Process Synchronization. Operating System Concepts 9 th Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationDining Philosophers, Semaphores
CS 220: Introduction to Parallel Computing Dining Philosophers, Semaphores Lecture 27 Today s Schedule Dining Philosophers Semaphores Barriers Thread Safety 4/30/18 CS 220: Parallel Computing 2 Today s
More informationChapter 6: Process Synchronization. Operating System Concepts 9 th Edit9on
Chapter 6: Process Synchronization Operating System Concepts 9 th Edit9on Silberschatz, Galvin and Gagne 2013 Objectives To present the concept of process synchronization. To introduce the critical-section
More information9/30/2014. CS341: Operating System High Level Construct: Monitor Deadlock Conditions Prevention, Avoidance Detection and Recovery
CS341: Operating System High Level Construct: Monitor Conditions Prevention, Avoidance Detection and Recovery Lect24: 1 st Oct 2014 Dr. A. Sahu Dept of Comp. Sc. & Engg. Indian Institute of Technology
More informationRoadmap. Tevfik Koşar. CSE 421/521 - Operating Systems Fall Lecture - X Deadlocks - I. University at Buffalo. Synchronization structures
CSE 421/521 - Operating Systems Fall 2012 Lecture - X Deadlocks - I Tevfik Koşar University at Buffalo October 2nd, 2012 1 Roadmap Synchronization structures Problems with Semaphores Monitors Condition
More informationRoadmap. Problems with Semaphores. Semaphores. Monitors. Monitor - Example. Tevfik Koşar. CSE 421/521 - Operating Systems Fall 2012
CSE 421/521 - Operating Systems Fall 2012 Lecture - X Deadlocks - I Tevfik Koşar Synchronization structures Problems with Semaphores Monitors Condition Variables Roadmap The Deadlock Problem Characterization
More informationParalleland Distributed Programming. Concurrency
Paralleland Distributed Programming Concurrency Concurrency problems race condition synchronization hardware (eg matrix PCs) software (barrier, critical section, atomic operations) mutual exclusion critical
More informationSemaphores INF4140. Lecture 3. 0 Book: Andrews - ch.04 ( ) INF4140 ( ) Semaphores Lecture 3 1 / 34
Semaphores INF4140 13.09.12 Lecture 3 0 Book: Andrews - ch.04 (4.1-4.4) INF4140 (13.09.12 ) Semaphores Lecture 3 1 / 34 Overview Last lecture: Locks and Barriers (complex techniques) No clear difference
More informationConsistency: Strict & Sequential. SWE 622, Spring 2017 Distributed Software Engineering
Consistency: Strict & Sequential SWE 622, Spring 2017 Distributed Software Engineering Review: Real Architectures N-Tier Web Architectures Internet Clients External Cache Internal Cache Web Servers Misc
More informationSemaphores. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University
Semaphores Jinkyu Jeong (jinkyu@skku.edu) Computer Systems Laboratory Sungkyunkwan University http://csl.skku.edu EEE3052: Introduction to Operating Systems, Fall 2017, Jinkyu Jeong (jinkyu@skku.edu) Synchronization
More informationChapter 6: Process Synchronization. Operating System Concepts 8 th Edition,
Chapter 6: Process Synchronization, Silberschatz, Galvin and Gagne 2009 Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores
More informationProcess Synchronization
Chapter 7 Process Synchronization 1 Chapter s Content Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors 2 Background
More informationChapter 7: Process Synchronization. Background. Illustration
Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors Synchronization in Solaris
More informationQuiz on Tuesday April 13. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 4. Java facts and questions. Things to try in Java
CS 361 Concurrent programming Drexel University Fall 2004 Lecture 4 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
More informationChapter 7: Process Synchronization. Background
Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors Synchronization in Solaris
More informationBackground. Module 6: Process Synchronization. Bounded-Buffer (Cont.) Bounded-Buffer. Background
Module 6: Process Synchronization Background Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors Synchronization
More informationProcess Synchronization
Process Synchronization Daniel Mosse (Slides are from Silberschatz, Galvin and Gagne 2013 and Sherif Khattab) Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution
More informationChapter 6: Process Synchronization. Module 6: Process Synchronization
Chapter 6: Process Synchronization Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization
More informationCOMP 150-CCP Concurrent Programming. Lecture 12: Deadlock. Dr. Richard S. Hall
COMP 150-CCP Concurrent Programming Lecture 12: Deadlock Dr. Richard S. Hall rickhall@cs.tufts.edu Concurrent programming February 28, 2008 Scenario Process 1 gets the lock for object A and wants to lock
More informationChapter 5: Process Synchronization. Operating System Concepts 9 th Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationCS3502 OPERATING SYSTEMS
CS3502 OPERATING SYSTEMS Spring 2018 Synchronization Chapter 6 Synchronization The coordination of the activities of the processes Processes interfere with each other Processes compete for resources Processes
More informationSemaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }
Semaphore Semaphore S integer variable Two standard operations modify S: wait() and signal() Originally called P() and V() Can only be accessed via two indivisible (atomic) operations wait (S) { while
More informationCS 361 Concurrent programming Drexel University Fall 2004 Lecture 8. Proof by contradiction. Proof of correctness. Proof of mutual exclusion property
CS 361 Concurrent programming Drexel University Fall 2004 Lecture 8 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Objectives Introduce Concept of Critical-Section Problem Hardware and Software Solutions of Critical-Section Problem Concept of Atomic Transaction Operating Systems CS
More information9/29/2014. CS341: Operating System Mid Semester Model Solution Uploaded Semaphore ADT: wait(), signal()
CS341: Operating System Mid Semester Model Solution Uploaded Semaphore ADT: wait(), signal() Lect23: 30 th Sept 2014 Dr. A. Sahu Dept of Comp. Sc. & Engg. Indian Institute of Technology Guwahati Classical
More informationConcurrent Programming
Indian Institute of Science Bangalore, India भ रत य व ज ञ न स स थ न ब गल र, भ रत SE 292: High Performance Computing [3:0][Aug:2014] Concurrent Programming Yogesh Simmhan Adapted from Intro to Concurrent
More informationMultithreaded Programming Part II. CSE 219 Stony Brook University, Department of Computer Science
Multithreaded Programming Part II CSE 219 Stony Brook University, Thread Scheduling In a Java application, main is a thread on its own Once multiple threads are made Runnable the thread scheduler of the
More informationSynchronization problems with semaphores
Synchronization problems with semaphores Lecture 4 of TDA384/DIT391 (Principles of Concurrent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2017/2018 Today
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization
More informationCSC Systems Programming Fall Lecture - XIV Concurrent Programming. Tevfik Ko!ar. Louisiana State University. November 2nd, 2010
CSC 4304 - Systems Programming Fall 2010 Lecture - XIV Concurrent Programming Tevfik Ko!ar Louisiana State University November 2nd, 2010 1 Concurrency Issues 2 Concurrency Issues 3 Synchronization Mechanism
More information3C03 Concurrency: Starvation and Deadlocks
3C03 Concurrency: Starvation and Deadlocks Wolfgang Emmerich 1 Goals Reader/Writer problem Starvation Dining Philosophers Problem Deadlocks Liveness Analysis using LTS 2 1 Reader / Writer Problem Monitors
More informationChapter 5: Process Synchronization
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationData Races and Deadlocks! (or The Dangers of Threading) CS449 Fall 2017
Data Races and Deadlocks! (or The Dangers of Threading) CS449 Fall 2017 Data Race Shared Data: 465 1 8 5 6 209? tail A[] thread switch Enqueue(): A[tail] = 20; tail++; A[tail] = 9; tail++; Thread 0 Thread
More informationSilberschatz and Galvin Chapter 6
Silberschatz and Galvin Chapter 6 Process Synchronization CPSC 410--Richard Furuta 2/26/99 1 Topics discussed Process synchronization Mutual exclusion--hardware Higher-level abstractions Ð Semaphores Ð
More informationOnly one thread can own a specific monitor
Java 5 Notes Threads inherit their priority and daemon properties from their creating threads The method thread.join() blocks and waits until the thread completes running A thread can have a name for identification
More informationReintroduction to Concurrency
Reintroduction to Concurrency The execution of a concurrent program consists of multiple processes active at the same time. 9/25/14 7 Dining philosophers problem Each philosopher spends some time thinking
More informationProcess Synchronization(2)
CSE 3221.3 Operating System Fundamentals No.6 Process Synchronization(2) Prof. Hui Jiang Dept of Computer Science and Engineering York University Semaphores Problems with the software solutions. Not easy
More informationWeek 7. Concurrent Programming: Thread Synchronization. CS 180 Sunil Prabhakar Department of Computer Science Purdue University
Week 7 Concurrent Programming: Thread Synchronization CS 180 Sunil Prabhakar Department of Computer Science Purdue University Announcements Exam 1 tonight 6:30 pm - 7:30 pm MTHW 210 2 Outcomes Understand
More informationMore Synchronization; Concurrency in Java. CS 475, Spring 2018 Concurrent & Distributed Systems
More Synchronization; Concurrency in Java CS 475, Spring 2018 Concurrent & Distributed Systems Review: Semaphores Synchronization tool that provides more sophisticated ways (than Mutex locks) for process
More informationDeadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018
Deadlock and Monitors CS439: Principles of Computer Systems September 24, 2018 Bringing It All Together Processes Abstraction for protection Define address space Threads Share (and communicate) through
More informationChapter 6 Synchronization
Chapter 6 Synchronization Da-Wei Chang CSIE.NCKU Source: Abraham Silberschatz, Peter B. Galvin, and Greg Gagne, "Operating System Concepts", 9th Edition, Wiley. 1 Outline Background The Critical-Section
More informationPre- and post- CS protocols. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 7. Other requirements for a mutual exclusion algorithm
CS 361 Concurrent programming Drexel University Fall 2004 Lecture 7 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
More informationProcess Synchronization
Process Synchronization Reading: Silberschatz chapter 6 Additional Reading: Stallings chapter 5 EEL 358 1 Outline Concurrency Competing and Cooperating Processes The Critical-Section Problem Fundamental
More informationOperating Systems. Thread Synchronization Primitives. Thomas Ropars.
1 Operating Systems Thread Synchronization Primitives Thomas Ropars thomas.ropars@univ-grenoble-alpes.fr 2017 2 Agenda Week 42/43: Synchronization primitives Week 44: Vacation Week 45: Synchronization
More informationChapter 6: Synchronization
Chapter 6: Synchronization Module 6: Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization
More informationConcurrent Object Oriented Languages
Concurrent Object Oriented Languages Semaphores wiki.eecs.yorku.ca/course/6490a Semaphores A semaphore is a datatype. Its values are nonnegative integers. A semaphore, say s, supports two atomic operations:
More informationTHREADS & CONCURRENCY
27/04/2018 Sorry for the delay in getting slides for today 2 Another reason for the delay: Yesterday: 63 posts on the course Piazza yesterday. A7: If you received 100 for correctness (perhaps minus a late
More informationOS Process Synchronization!
OS Process Synchronization! Race Conditions! The Critical Section Problem! Synchronization Hardware! Semaphores! Classical Problems of Synchronization! Synchronization HW Assignment! 3.1! Concurrent Access
More informationDealing with Issues for Interprocess Communication
Dealing with Issues for Interprocess Communication Ref Section 2.3 Tanenbaum 7.1 Overview Processes frequently need to communicate with other processes. In a shell pipe the o/p of one process is passed
More informationDeadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018
Deadlock and Monitors CS439: Principles of Computer Systems February 7, 2018 Last Time Terminology Safety and liveness Atomic Instructions, Synchronization, Mutual Exclusion, Critical Sections Synchronization
More informationProcess Synchronization. CISC3595, Spring 2015 Dr. Zhang
Process Synchronization CISC3595, Spring 2015 Dr. Zhang 1 Concurrency OS supports multi-programming In single-processor system, processes are interleaved in time In multiple-process system, processes execution
More informationBack to synchronization
Back to synchronization The dining philosophers problem Deadlocks o Modeling deadlocks o Dealing with deadlocks Operating Systems, 28, I. Dinur, D. Hendler and R. Iakobashvili The Dining Philosophers Problem
More informationConcurrency pros and cons. Concurrent Programming Problems. Mutual Exclusion. Concurrency is good for users
Concurrency pros and cons Con Programming Problems OS Spring 2009 Concurrency is good for users One of the reasons for multiprogramming Working on the same problem, simultaneous execution of programs,
More informationOperating Systems Antonio Vivace revision 4 Licensed under GPLv3
Operating Systems Antonio Vivace - 2016 revision 4 Licensed under GPLv3 Process Synchronization Background A cooperating process can share directly a logical address space (code, data) or share data through
More informationYet another synchronization problem
Yet another synchronization problem The dining philosophers problem Deadlocks o Modeling deadlocks o Dealing with deadlocks Operating Systems, 25, Meni Adler, Danny Hendler & Roie Zivan The Dining Philosophers
More informationCSE Traditional Operating Systems deal with typical system software designed to be:
CSE 6431 Traditional Operating Systems deal with typical system software designed to be: general purpose running on single processor machines Advanced Operating Systems are designed for either a special
More informationDistributed Real-Time Control Systems. Lecture 21 Condition Variables Typical ConcurrencyProblems
Distributed Real-Time Control Systems Lecture 21 Condition Variables Typical ConcurrencyProblems 1 Synchronization between Tasks Consider a distributed control system where the sensor reading and control
More informationOperating systems. Lecture 12
Operating systems. Lecture 12 Michał Goliński 2018-12-18 Introduction Recall Critical section problem Peterson s algorithm Synchronization primitives Mutexes Semaphores Plan for today Classical problems
More informationThe Dining Philosophers Problem CMSC 330: Organization of Programming Languages
The Dining Philosophers Problem CMSC 0: Organization of Programming Languages Threads Classic Concurrency Problems Philosophers either eat or think They must have two forks to eat Can only use forks on
More informationPlan. Demos. Next Project. CSCI [4 6]730 Operating Systems. Hardware Primitives. Process Synchronization Part II. Synchronization Part 2
Plan Demos Project: Due» Demos following week (Wednesday during class time) Next Week» New phase of presentations» Deadlock, finish synchronization Course Progress:» History, Structure, Processes, Threads,
More information