CS 361 Concurrent programming Drexel University Spring 2000 Lecture 14. The dining philosophers problem
|
|
- Holly Nichols
- 6 years ago
- Views:
Transcription
1 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 for their own use. 1 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. 2 1
2 Dining philosophers solved through semaphores Central server object that records states of philosophers. Avoids deadlock/livelock, but doesn t address the issue of starvation by a philosopher 3 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]). 4 2
3 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]). 5 Dining philosophers server import Utilities.*; import Synchronization.*; class DiningServer extends MyObject { private static final int THINKING = 0, HUNGRY = 1, EATING = 2; private int numphils = 0; private int[] state = null; private BinarySemaphore[] self = null; 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); 6 3
4 Dining philosophers server, cont. 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(mutex); state[i] = HUNGRY; test(i); V(mutex); P(self[i]); public void putforks(int i) { P(mutex); state[i] = THINKING; test(left(i)); test(right(i)); V(mutex); private void test(int k) { if (state[left(k)]!= EATING && state[right(k)]!= EATING && state[k] == HUNGRY) { state[k] = EATING; V(self[k]); 7 Dining philosophers driver import Utilities.*; class Philosopher extends MyObject implements Runnable { private intid = 0; private int napthink = 0; // both are in private int napeat = 0; // milliseconds private DiningServer ds = null; public Philosopher(String name, int id, int napthink, int napeat, DiningServer ds) { super(name + " " + id); this.id = id; this.napthink = napthink; this.napeat = napeat; this.ds = ds; System.out.println(getName() + " is alive, napthink=" + napthink + ", napeat=" + napeat); new Thread(this).start(); 8 4
5 D.P. driver cont. private void think() { int napping; napping = 1 + (int) random(napthink); System.out.println("age()=" + age() + ", " + getname() + " is thinking for " + napping + " ms"); nap(napping); private void eat() { int napping; napping = 1 + (int) random(napeat); System.out.println("age()=" + age() + ", " + getname() + " is eating for " + napping + " ms"); nap(napping); public void run() { while (true) { think(); System.out.println("age()=" + age() + ", " + getname() + " wants to eat"); ds.takeforks(id); eat(); ds.putforks(id); 9 class DiningPhilosophers extends MyObject { public static void main(string[] args) { D.P. driver cont. // 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]); 10 5
6 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); 11 Avoiding starvation This solution avoids deadlock but doesn t guarantee that no philosopher will starve. Stallings came up with a solution that avoids starvation. 12 6
7 Avoiding starvation import Utilities.*; import Synchronization.*; 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)); 13 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) { state[i] = HUNGRY; P(room); P(fork[i]); P(fork[right(i)]); // since the counting semaphore 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; 14 7
8 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. 15 Maximal parallelism The problem with this 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. We could have every other philosopher eating here. 16 8
9 Another non-maximal solution public void takeforks(int i) { state[i] = HUNGRY; if (i > 0) { P(fork[i]); P(fork[right(i)]); else { P(fork[right(i)]); P(fork[i]); state[i] = EATING; Odd philosopher out takes the fork in his/her other hand. Still doesn t achieve maximal parallelism. 17 Exercise: avoid starvation another way 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. Or you can count the number of times it has not been able to pick up its forks, or based on how many times each fork has been picked up. 18 9
10 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 time time because either they will deadlock or you will still have starvation. 19 Bounded buffer using real Java class BoundedBuffer { producer thread private int numslots = 0; private double[] buffer = null; private int putin = 0, takeout = 0; private int count = 0; // designed for a single // and a single consumer thread public BoundedBuffer(int numslots) { if (numslots <= 0) throw new IllegalArgumentException("numSlots<=0"); this.numslots = numslots; buffer = new double[numslots]; System.out.println("BoundedBuffer alive, numslots=" + numslots); 20 10
11 Bounded buffer using real Java public synchronized void deposit(double value) { while (count == numslots) try { wait(); catch (InterruptedException e) { System.err.println("interrupted out of wait"); buffer[putin] = value; putin = (putin + 1) % numslots; count++; // wake up the consumer if (count == 1) notify(); // since it might be waiting System.out.println(" after deposit, count=" + count + ", putin=" + putin); 21 Bounded buffer using real Java public synchronized double fetch() { double value; while (count == 0) try { wait(); catch (InterruptedException e) { System.err.println("interrupted out of wait"); value = buffer[takeout]; takeout = (takeout + 1) % numslots; count--; // wake up the producer if (count == numslots-1) notify(); // since it might be waiting System.out.println(" after fetch, count=" + count + ", takeout=" + takeout); return value; 22 11
12 Dining philosophers with real Java // Real Java code for solving the Dining Philosophers problem. class DiningServer { private boolean checkstarving = false; private int numphils = 0; private int[] state = null; private static final int THINKING = 0, HUNGRY = 1, STARVING = 2, EATING = 3; publicdiningserver(int numphils, boolean checkstarving) { this.numphils = numphils; this.checkstarving = checkstarving; state = new int[numphils]; for (int i = 0; i < numphils; i++) state[i] = THINKING; System.out.println("DiningServer: checkstarving=" + checkstarving); 23 Dining philosophers with real Java // Real Java code for solving the Dining Philosophers problem. class DiningServer { private boolean checkstarving = false; private int numphils = 0; private int[] state = null; private static final int THINKING = 0, HUNGRY = 1, STARVING = 2, EATING = 3; publicdiningserver(int numphils, boolean checkstarving) { this.numphils = numphils; this.checkstarving = checkstarving; state = new int[numphils]; for (int i = 0; i < numphils; i++) state[i] = THINKING; System.out.println("DiningServer: checkstarving=" + checkstarving); 24 12
13 Dining philosophers with real Java private final int left(int i) { return (numphils + i - 1) % numphils; private final int right(int i) { return (i + 1) % numphils; private void seeifstarving(int k) { if (state[k] == HUNGRY && state[left(k)]!= STARVING && state[right(k)]!= STARVING) { state[k] = STARVING; System.out.println("philosopher " + k + " is STARVING"); 25 Dining philosophers with real Java private void test(int k, boolean checkstarving) { if (state[left(k)]!= EATING && state[left(k)]!= STARVING && (state[k] == HUNGRY state[k] == STARVING) && state[right(k)]!= STARVING && state[right(k)]!= EATING) state[k] = EATING; else if (checkstarving) seeifstarving(k); // simplistic naive check for starvation public synchronized void takeforks(int i) { state[i] = HUNGRY; test(i, false); while (state[i]!= EATING) try {wait(); catch (InterruptedException e) { 26 13
14 Dining philosophers with real Java public synchronized void putforks(int i) { state[i] = THINKING; test(left(i), checkstarving); test(right(i), checkstarving); notifyall(); 27 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)
15 Database reader/writer solution import Utilities.*; import Synchronization.*; class Database extends MyObject { private int numreaders = 0; private BinarySemaphore mutex = new BinarySemaphore(1); private BinarySemaphore ok = new BinarySemaphore(1); public Database() { super("database"); 29 Reader code public void startread(int i) { P(mutex); 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); V(mutex); public void endread(int i) { P(mutex); numreaders--; System.out.println(" age=" + age() + " reader " + i + " finished reading, numreaders=" + numreaders); if (numreaders == 0) V(ok); V(mutex); 30 15
16 Writer code 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); 31 Notes on reader/writer solution 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
17 Preventing starvation of writers How could we avoid starvation of writers (from section While readers in the active queue are working, writers are blocked. If a writer is waiting, no reader can start reading. After a writer finishes, it sweeps all the waiting readers into the active queue. In this way readers can t starve the writers or vice versa. In other words, they try to alternate between readers and writers to the extent that they can. Increase parallelism without starvation by letting all queued readers into the active queue. (Have to be careful to make sure that differing speeds of writers and readers doesn t mess things up.) 33 How do you do this? Hint: try time stamping a reader s or writer s arrival to keep track of who should proceed or not
18 Reader/writer code with pseudo Java Readers and Writers // This is Java-like pseudocode, but NOT valid Java // because the signaling discipline and condition // variables are wrong. import Utilities.*; import Synchronization.*; class Database extends MyObject { private int numreaders = 0; private boolean iswriting = false; private ConditionVariable OKtoRead = new ConditionVariable(); private ConditionVariable OKtoWrite = new ConditionVariable(); 35 Reader/writer code with pseudo Java public synchronized void startread(int i) { if (iswriting) wait(oktoread); else if (!empty(oktowrite)) { wait(oktoread); // new incoming readers cannot starve writers numreaders++; notify(oktoread); // when a writer finishes, all waiting readers start public synchronized void endread(int i) { numreaders--; if (numreaders == 0) notify(oktowrite); 36 18
19 Reader/writer code with pseudo Java public synchronized void startwrite(int i) { if (numreaders!= 0 iswriting) wait(oktowrite); iswriting = true; public synchronized void endwrite(int i) { iswriting = false; if (!empty(oktoread)) notify(oktoread); else notify(oktowrite); // nor do writers starve readers 37 Reader/writer code with real Java /* Real Java code. * Fair to both readers and writers in the sense that as * soon as a writer arrives (while the database is being * read, say) then no more newly arriving readers are allowed * to start reading. Instead the newly arriving readers * must wait until after that writer has written. That * writer will then sweep into reading the database those * readers that had to wait. However a finishing writer * will sweep into reading the database ALL waiting readers, * even those readers that arrived after a writer that * arrived after the current writer that is just finishing. */ import Utilities.*; 38 19
20 Reader/writer code with real Java class Database extends MyObject { private int numreaders = 0; private int numwriters = 0; private int numwaitingreaders = 0; private int numwaitingwriters = 0; private boolean oktowrite = true; private long startwaitingreaderstime = 0; public Database() { super("rwdb"); 39 Reader/writer code with real Java public synchronized void startread(int i) { long readerarrivaltime = 0; if (numwaitingwriters > 0 numwriters > 0) { numwaitingreaders++; readerarrivaltime = age(); while (readerarrivaltime >= startwaitingreaderstime) try {wait(); catch (InterruptedException e) { numwaitingreaders--; numreaders++; public synchronized void endread(int i) { numreaders--; oktowrite = numreaders == 0; if (oktowrite) notifyall(); 40 20
21 Reader/writer code with real Java public synchronized void startwrite(int i) { if (numreaders > 0 numwriters > 0) { numwaitingwriters++; oktowrite = false; while (!oktowrite) try {wait(); catch (InterruptedException e) { numwaitingwriters--; oktowrite = false; numwriters++; public synchronized void endwrite(int i) { numwriters--; // ASSERT(numWriters==0) oktowrite = numwaitingreaders == 0; startwaitingreaderstime = age(); notifyall(); 41 Reader/writer code with real Java /*... Example compile and run(s) D:\>javac rwmo.java rwdr.java D:\>java ReadersWriters -E5 -W3 -e2 -w2 -R5 ReadersWriters: numreaders=5, numwriters=3, rnap=2, wnap=2, runtime=5 age=110, Reader1 napping for 391 ms age=110, Reader3 napping for 1319 ms age=110, Reader0 napping for 308 ms age=110, Reader4 napping for 1597 ms age=160, Reader2 napping for 1026 ms age=160, WRITER2 napping for 1401 ms age=160, WRITER1 napping for 874 ms age=160, WRITER0 napping for 1119 ms All threads started age=440, Reader0 wants to read age=440, Reader0 reading for 1530 ms age=490, Reader1 wants to read age=490, Reader1 reading for 93 ms age=600, Reader1 finished reading age=600, Reader1 napping for 1931 ms 42 age=1040, WRITER1 wants to write age=1210, Reader2 wants to read 21
22 Reader/writer code with real Java /*... Example compile and run(s) D:\>javac rwmo.java rwdr.java D:\>java ReadersWriters -E5 -W3 -e2 -w2 -R5 ReadersWriters: numreaders=5, numwriters=3, rnap=2, wnap=2, runtime=5 age=110, Reader1 napping for 391 ms age=110, Reader3 napping for 1319 ms age=110, Reader0 napping for 308 ms age=110, Reader4 napping for 1597 ms age=160, Reader2 napping for 1026 ms age=160, WRITER2 napping for 1401 ms age=160, WRITER1 napping for 874 ms age=160, WRITER0 napping for 1119 ms All threads started age=440, Reader0 wants to read age=440, Reader0 reading for 1530 ms age=490, Reader1 wants to read age=490, Reader1 reading for 93 ms age=600, Reader1 finished reading age=600, Reader1 napping for 1931 ms 43 Reader/writer code with real Java age=1040, WRITER1 wants to write age=1210, Reader2 wants to read age=1320, WRITER0 wants to write age=1430, Reader3 wants to read age=1590, WRITER2 wants to write age=1760, Reader4 wants to read age=1980, Reader0 finished reading age=1980, Reader0 napping for 329 ms age=1980, WRITER1 writing for 1144 ms age=2310, Reader0 wants to read age=2530, Reader1 wants to read age=3130, WRITER1 finished writing age=3130, WRITER1 napping for 774 ms age=3130, Reader4 reading for 985 ms age=3180, Reader2 reading for 1007 ms age=3240, Reader3 reading for 472 ms age=3240, Reader0 reading for 1436 ms age=3240, Reader1 reading for 1894 ms age=3680, Reader3 finished reading age=3680, Reader3 napping for 1759 ms age=3900, WRITER1 wants to write 44 22
The dining philosophers problem. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 13
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
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 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 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 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 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 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 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 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 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 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 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 information5 Dining Philosophers. Template for Philosopher. Naive Solution. while (food available) /*pick up forks*/ eat; /*put down forks*/ think awhile;
5 Dining Philosophers Philosopher 4 Philosopher 3 Philosopher 0 while(food available) pick up 2 adj. forks; put down forks; Philosopher 1 Philosopher 2 90 Template for Philosopher /*pick up forks*/ /*put
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 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 informationHomework 12 Due Wednesday, 12/8/10
Homework 12 Due Wednesday, 12/8/10 Please turn in your homework solutions online at http://www.dci.pomona.edu/tools-bin/cs131upload.php before the beginning of class on the due date. 1. (10 points) Atomicity
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 informationMemory system behavior: volatile variables. CS 361 Concurrent programming Drexel University Fall 2004 Lecture 6. Volatile variables and concurrency
CS 361 Concurrent programming Dreel University Fall 2004 Lecture 6 Bruce Char and Vera Zaychik. All rights reserved by the author. Permission is given to students enrolled in CS361 Fall 2004 to reproduce
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 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 informationOutline for Today. 5 Dining Philosophers. Template for Philosopher. Naive Solution. Objective: Administrative details:
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
More informationCMSC 330: Organization of Programming Languages. The Dining Philosophers Problem
CMSC 330: Organization of Programming Languages Threads Classic Concurrency Problems The Dining Philosophers Problem Philosophers either eat or think They must have two forks to eat Can only use forks
More informationCS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004
CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004 Lecture 9: Readers-Writers and Language Support for Synchronization 9.1.2 Constraints 1. Readers can access database
More informationTwo Types of Semaphores
Two Types of Semaphores Counting semaphore integer value can range over an unrestricted domain. Binary semaphore integer value can range only between 0 and 1; can be simpler to implement. Can implement
More informationCMSC 330: Organization of Programming Languages. Threads Classic Concurrency Problems
: Organization of Programming Languages Threads Classic Concurrency Problems The Dining Philosophers Problem Philosophers either eat or think They must have two forks to eat Can only use forks on either
More informationThere are 8 total numbered pages, 6 Questions. You have 60 minutes. Budget your time carefully!
UNIVERSITY OF TORONTO FACULTY OF APPLIED SCIENCE AND ENGINEERING MIDTERM EXAMINATION, March, 2017 Third Year Materials ECE344H1 - Operating Systems Calculator Type: 2 Exam Type: A Examiner D. Yuan Please
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 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 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 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 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 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 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 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 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 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 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 informationTopic 4: Synchronization with Semaphores
CS 414 : Operating Systems UNIVERSITY OF VIRGINIA Department of Computer Science Fall 2005 Topic 4: Synchronization with Semaphores Readings for this topic: Sections 6.1-6.6 The too-much-milk solution
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 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 informationPart IV Other Systems: I Java Threads
Part IV Other Systems: I Java Threads Spring 2019 C is quirky, flawed, and an enormous success. 1 Dennis M. Ritchie Java Threads: 1/6 Java has two ways to create threads: Create a new class derived from
More informationSFDV3006 Concurrent Programming
SFDV3006 Concurrent Programming Lecture 6 Deadlocks, livelocks, Starvation Introduction Last week we covered semaphore and how to use them for both synchronization and condition synchronization This week
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 informationContribution:javaMultithreading Multithreading Prof. Dr. Ralf Lämmel Universität Koblenz-Landau Software Languages Team
http://101companies.org/wiki/ Contribution:javaMultithreading Multithreading Prof. Dr. Ralf Lämmel Universität Koblenz-Landau Software Languages Team Non-101samples available here: https://github.com/101companies/101repo/tree/master/technologies/java_platform/samples/javathreadssamples
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 informationModels of concurrency & synchronization algorithms
Models of concurrency & synchronization algorithms Lecture 3 of TDA383/DIT390 (Concurrent Programming) Carlo A. Furia Chalmers University of Technology University of Gothenburg SP3 2016/2017 Today s menu
More informationSemaphores. A semaphore is an object that consists of a. methods (e.g., functions): signal and wait. semaphore. method signal. counter.
Semaphores 1 Semaphores A semaphore is an object that consists of a counter, a waiting list of processes, and two methods (e.g., functions): signal and wait. method signal method wait counter waiting list
More informationComputer Networks. Process Cooperation Multithreaded Programming in Java. Laszlo Böszörmenyi Computer Networks Processes - 1
Computer Networks Process Cooperation Multithreaded Programming in Java ß ß Laszlo Böszörmenyi Computer Networks Processes - 1 Processes and threads A process is a sequential flow of control that is able
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 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 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 informationPrinciples of Software Construction: Concurrency, Part 2
Principles of Software Construction: Concurrency, Part 2 Josh Bloch Charlie Garrod School of Computer Science 1 Administrivia Homework 5a due now Homework 5 framework goals: Functionally correct Well documented
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 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 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(2)
EECS 3221.3 Operating System Fundamentals No.6 Process Synchronization(2) Prof. Hui Jiang Dept of Electrical Engineering and Computer Science, York University Semaphores Problems with the software solutions.
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 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 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 informationCSC501 Operating Systems Principles. Process Synchronization
CSC501 Operating Systems Principles Process Synchronization 1 Last Lecture q Process Scheduling Question I: Within one second, how many times the timer interrupt will occur? Question II: Within one second,
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 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 informationTHREADS & CONCURRENCY
4/26/16 Announcements BRING YOUR CORNELL ID TO THE PRELIM. 2 You need it to get in THREADS & CONCURRENCY Prelim 2 is next Tonight BRING YOUR CORNELL ID! A7 is due Thursday. Our Heap.java: on Piazza (A7
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 informationProgramming Languages
Programming Languages Tevfik Koşar Lecture - XXVI April 27 th, 2006 1 Roadmap Shared Memory Synchronization Spin Locks Barriers Semaphores Monitors 2 1 Memory Architectures Distributed Memory Shared Memory
More informationThreads and Parallelism in Java
Threads and Parallelism in Java Java is one of the few main stream programming languages to explicitly provide for user-programmed parallelism in the form of threads. A Java programmer may organize a program
More informationCOMP 322: Fundamentals of Parallel Programming. Lecture 30: Java Synchronizers, Dining Philosophers Problem
COMP 322: Fundamentals of Parallel Programming Lecture 30: Java Synchronizers, Dining Philosophers Problem Vivek Sarkar, Shams Imam Department of Computer Science, Rice University Contact email: vsarkar@rice.edu,
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 informationSynchronized Methods of Old Versions of Java
Administrivia Assignment #4 is out Due Thursday April 8, 10:00pm no late assignments will be accepted Sign up in labs next week for a demo time In case you hadn t noticed Classes end Thursday April 15
More informationChapter 2 Processes and Threads. Interprocess Communication Race Conditions
Chapter 2 Processes and Threads [ ] 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling 85 Interprocess Communication Race Conditions Two processes want to access shared memory at
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 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 informationCS61B, Spring 2003 Discussion #17 Amir Kamil UC Berkeley 5/12/03
CS61B, Spring 2003 Discussion #17 Amir Kamil UC Berkeley 5/12/03 Topics: Threading, Synchronization 1 Threading Suppose we want to create an automated program that hacks into a server. Many encryption
More informationLecture 27: Safety and Liveness Properties, Java Synchronizers, Dining Philosophers Problem
COMP 322: Fundamentals of Parallel Programming Lecture 27: Safety and Liveness Properties, Java Synchronizers, Dining Philosophers Problem Mack Joyner and Zoran Budimlić {mjoyner, zoran}@rice.edu http://comp322.rice.edu
More information