CS 10: Problem solving via Object Oriented Programming Winter 2017

Similar documents
Classical Synchronization Problems. Copyright : University of Illinois CS 241 Staff 1

Deadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018

Overview. CMSC 330: Organization of Programming Languages. Concurrency. Multiprocessors. Processes vs. Threads. Computation Abstractions

The Dining Philosophers Problem CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. The Dining Philosophers Problem

CMSC 330: Organization of Programming Languages. Threads Classic Concurrency Problems

Deadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018

Concurrency. Chapter 5

Concurrency: Deadlock and Starvation. Chapter 6

Semaphores. Jinkyu Jeong Computer Systems Laboratory Sungkyunkwan University

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

Lecture Topics. Announcements. Today: Concurrency (Stallings, chapter , 5.7) Next: Exam #1. Self-Study Exercise #5. Project #3 (due 9/28)

CS 2112 Lecture 20 Synchronization 5 April 2012 Lecturer: Andrew Myers

Week 7. Concurrent Programming: Thread Synchronization. CS 180 Sunil Prabhakar Department of Computer Science Purdue University

Sections 01 (11:30), 02 (16:00), 03 (8:30) Ashraf Aboulnaga & Borzoo Bonakdarpour

More Synchronization; Concurrency in Java. CS 475, Spring 2018 Concurrent & Distributed Systems

Synchronization. CS 475, Spring 2018 Concurrent & Distributed Systems

Last Class: Monitors. Real-world Examples

Threads. Definitions. Process Creation. Process. Thread Example. Thread. From Volume II

SSC - Concurrency and Multi-threading Java multithreading programming - Synchronisation (II)

CMSC 330: Organization of Programming Languages. Concurrency & Multiprocessing

Deadlocks. Deadlock in Resource Sharing Environment. CIT 595 Spring Recap Example. Representing Deadlock

Contribution:javaMultithreading Multithreading Prof. Dr. Ralf Lämmel Universität Koblenz-Landau Software Languages Team

What is the Race Condition? And what is its solution? What is a critical section? And what is the critical section problem?

PROCESS SYNCHRONIZATION

Chapter 6: Process Synchronization

SFDV3006 Concurrent Programming

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

CS 537 Lecture 8 Monitors. Thread Join with Semaphores. Dining Philosophers. Parent thread. Child thread. Michael Swift

Deadlock. Concurrency: Deadlock and Starvation. Reusable Resources

More on Synchronization and Deadlock

CMSC 330: Organization of Programming Languages

Computation Abstractions. Processes vs. Threads. So, What Is a Thread? CMSC 433 Programming Language Technologies and Paradigms Spring 2007

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

CS3502 OPERATING SYSTEMS

Deadlock. Disclaimer: some slides are adopted from Dr. Kulkarni s and book authors slides with permission 1

Operating Systems Antonio Vivace revision 4 Licensed under GPLv3

Multithreaded Programming Part II. CSE 219 Stony Brook University, Department of Computer Science

Lecture 8: September 30

COMP 150-CCP Concurrent Programming. Lecture 12: Deadlock. Dr. Richard S. Hall

CSC501 Operating Systems Principles. Process Synchronization

Synchronising Threads

Operating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy

Process Management And Synchronization

Synchronization COMPSCI 386

Chapter 5: Process Synchronization. Operating System Concepts Essentials 2 nd Edition

Semaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }

Lesson 6: Process Synchronization

Consistency: Strict & Sequential. SWE 622, Spring 2017 Distributed Software Engineering

CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring Lecture 8: Semaphores, Monitors, & Condition Variables

Deadlock CS 241. March 19, University of Illinois

What's wrong with Semaphores?

CS370 Operating Systems

Concurrency: Deadlock and Starvation. Chapter 6

Process Synchronization

Threading the Code. Self-Review Questions. Self-review 11.1 What is a thread and what is a process? What is the difference between the two?

Synchronization. Silvina Hanono Wachman Computer Science & Artificial Intelligence Lab M.I.T.

Chapters 5 and 6 Concurrency

Resource management. Real-Time Systems. Resource management. Resource management

COMP346 Winter Tutorial 4 Synchronization Semaphores

Chapter 6: Process Synchronization. Operating System Concepts 8 th Edition,

Synchronization Lecture 24 Fall 2018

Operating systems. Lecture 12

Java Threads. Introduction to Java Threads

Programming Languages

Deadlock. Only one process can use the resource at a time but once it s done it can give it back for use by another process.

2.c Concurrency Mutual exclusion & synchronization mutexes. Unbounded buffer, 1 producer, N consumers

Interprocess Communication By: Kaushik Vaghani

Last Class: Synchronization Problems!

Liveness properties. Deadlock

Performance Throughput Utilization of system resources

Process Synchronization. studykorner.org

Deadlock. Disclaimer: some slides are adopted from Dr. Kulkarni s and book authors slides with permission 1

Overview. Processes vs. Threads. Computation Abstractions. CMSC 433, Fall Michael Hicks 1

CS370 Operating Systems

Deadlock. Disclaimer: some slides are adopted from Dr. Kulkarni s and book authors slides with permission 1

27/04/2012. We re going to build Multithreading Application. Objectives. MultiThreading. Multithreading Applications. What are Threads?

CSE 451: Operating Systems Winter Lecture 7 Synchronization. Steve Gribble. Synchronization. Threads cooperate in multithreaded programs

Back to synchronization

Concept of a process

Semaphores. To avoid busy waiting: when a process has to wait, it will be put in a blocked queue of processes waiting for the same event

Semaphores. Semaphores. Semaphore s operations. Semaphores: observations

EECS 482 Introduction to Operating Systems

Operating Systems: William Stallings. Starvation. Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall

CS370 Operating Systems

Last Class: Synchronization Problems. Need to hold multiple resources to perform task. CS377: Operating Systems. Real-world Examples

Yet another synchronization problem

Interprocess Communication and Synchronization

OpenMP and more Deadlock 2/16/18

PESIT Bangalore South Campus

5. Liveness and Guarded Methods

Deadlocks. Copyright : University of Illinois CS 241 Staff 1

Implementing Mutual Exclusion. Sarah Diesburg Operating Systems CS 3430

Synchronization. CS 416: Operating Systems Design, Spring 2011 Department of Computer Science Rutgers University

Dealing with Issues for Interprocess Communication

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

CS11 Java. Fall Lecture 7

Threads and Parallelism in Java

Results of prelim 2 on Piazza

Concurrency & Synchronization. COMPSCI210 Recitation 25th Feb 2013 Vamsi Thummala Slides adapted from Landon Cox

Transcription:

CS 10: Problem solving via Object Oriented Programming Winter 2017 Tim Pierson 260 (255) Sudikoff SynchronizaGon

Agenda 1. Threads and interleaving execugon 2. Producer/consumer 3. Deadlock, starvagon 2

Threads are a way for mulgple processes to run concurrently Threads MyThread 1 Assume MyThread is a class that extends Thread Main program MyThread 2 MyThread must a implement a run method main() { MyThreadClass t = new MyThreadClass(); //start thread at run method, main thread keeps running t.start() //halt main until thread finishes t.join MyThread n ExecuGon begins by calling start on a MyThread object, run method then executes Can call join to halt main program ungl thread finishes 3

Concurrent threads can access the same resources, this can cause problems Concurrency MyThread 1 total+=1 Main program MyThread 2 total+=1 MyThread static total MyThread n total+=1 Threads can be interrupted at any Gme by the OperaGng System and another thread may be run When each thread tries to increment total, it gets a current copy of total, adds 1, then stores it back in memory What can go wrong? 4

Threads can be interrupted at any point, this can cause unexpected behavior Incrementer.java total is stagc (shared by all of same class) Two threads of same Incrementer class started Main program execugon blocked with joins Each thread increments total 1 million Gmes Each thread may be interrupted at any point IncremenGng total Get value of total from memory Add 1 Store new value back in memory Another thread might get value from memory between Gme when first thread got value and Gme when first thread wrote new value back In that case, the value of total will only be incremented by 1 not 2 5

Threads can be interrupted at any point, this can cause unexpected behavior IncrementerInterleaving.java Almost the same as Incrementer.java Each thread now keeps track of its name Each thread now prints to console (causing more Gme for interrupgons for other thread) Two threads try to increment total 5 Gmes SomeGmes it works, somegmes it doesn t, depends how threads were executed by OperaGng System Causes tricky debugging issues! Run several Gmes 6

Java provides the keyword synchronized to make some operagons atomic IncrementerTotal.java public class IncrementerTotal { int total = 0; public synchronized void inc() { total++; } } synchronized keyword in front of inc method means only one thread can be running this code at a Gme If mulgple threads try to run synchronized code, one thread runs, all others are blocked ungl first one finishes Once first thread finishes, another thread is selected to run synchronized makes this code atomic (e.g., as if it were one instrucgon) This synchronized approach is called a monitor (or mutex) 7

Java provides the keyword synchronized to make some operagons atomic IncrementerTotal.java Class that provides a synchronized method inc to ensure only one thread at a Gme can access inc method IncrementerSync.java Uses synchronized code to make sure only one thread at a Gme can update total Total is 2 million at complegon because threads don t step on each other 8

Agenda 1. Interleaving execugon 2. Producer/consumer 3. Deadlock, starvagon 9

Producers tell Consumers when ready, Consumers tell Producers when done Main idea Producer: Tell Consumer when item is ready (notify or notifyall) Block ungl woken up by Consumer that item handled (wait) Tell Consumer when next item is ready (notify or notifyall) Consumer: Block ungl woken up by Producer that item ready (wait) Process item and tell Producer when done (notify or notifyall) Block ungl woken up by Producer (wait) 10

Producers and Consumers synchronized with wait, notify or notifyall wait Removes thread from synchronized method Tells OperaGng System to put this thread into a list of waigng threads Allows another thread to enter synchronized method notify Tells OperaGng System to pick a waigng thread and let it run again (not a FIFO queue, OS decides take CS58 for more) Thread should check that condigons are met for it to congnue notifyall Wake up all waigng threads Each thread should check that condigons are met for it to congnue 11

Producer passing messages to Consumer using semaphore Example Time Producers checks if MessageBox empty, wait if not empty Consumers checks for message, wait if empty 12

Producer passing messages to Consumer using semaphore Example Time MessageBox empty, Producer puts message in MessageBox object Consumers wait for MessageBox nogficagon MessageBox put method synchronized so only one thread can be in method at a Gme 13

Producer passing messages to Consumer using semaphore Example Time Producers wait ungl MessageBox is empty Consumers wait for MessageBox nogficagon MessageBox now holds message MessageBox nogfies all threads waigng for MessageBox access using notifyall 14

Producer passing messages to Consumer using semaphore Example Time Producers wake up and check to see if message empty Not empty so all Producers wait again All waigng Consumers try to access message One succeeds and removes message, others wait 15

Producer passing messages to Consumer using semaphore Example Time Producer waits ungl MessageBox is empty All waigng Consumers try to access message One succeeds and removes message, others wait MessageBox take method synchronized so only one thread can be in method at a Gme take removes message from MessageBox 16

Producer passing messages to Consumer using semaphore Example Time Producer waits ungl MessageBox is empty Consumers wait ungl MessageBox if full MessageBox nogfies all threads waigng for MessageBox access using notifyall Producers may put message now 17

Producer/Consumer example shows how to use object as semaphore ProducerConsumer.java Create a MessageBox, Producer and Consumer Start Producer and Consumer running on different threads NOTE: no join, so main thread ends, while threads run Producer.java run method tries to put 5 messages into MessageBox Sleeps for random Gme between puts Consumer.java Takes messages from MessageBox Prints message 18

Producer/Consumer example shows how to use object as semaphore MessageBox.java Acts as a semaphore put Synchronized so only one thread runs method at a Gme Causes threads to block with wait if message not empty NOTE: empty check in a while loop, just because nogfied, doesn t mean another thread hasn t already put a message, must make this check! notifyall ager sehng message to wake up all Producers and Consumers (see note above) take Causes all Consumers to block with wait if message is null Makes check in while loop like put Nulls and returns message notifyall to wake up all Producers and Consumers 19

Agenda 1. Interleaving execugon 2. Producer/consumer 3. Deadlock, starvagon 20

SynchronizaGon can lead to two problems: deadlocks and starvagons Deadlock Objects lock resources ExecuGon cannot proceed because object need a resource another locked Object A locks resource 1 Object B locks resource 2 A needs resource 2 to proceed but B has it locked B needs resources 1 to proceed but A has it locked A and B are deadlocked StarvaCon Thread never gets resource it needs Thread A needs resource 1 to complete Other threads always take resource 1 before A can get it A is starved 21

Dinning Philosophers explains deadlock and starvagon Dinning Philosophers Problem set up Five philosophers (P 0 - P 4 ) sit at a table to eat spagheh There are forks between each of them (five total forks) Each philosopher needs two forks to eat Ager acquiring two forks, philosopher eats, then puts both forks down Another philosopher can then pick up and use fork previously put down (gross!) 22

Dinning Philosophers explains deadlock and starvagon Dinning Philosophers Naïve approach Each philosopher picks up fork on leg Then picks up fork on right Deadlock occurs if all philosophers get leg fork, none can get right fork 23

For deadlock to occur four condigons must be met Deadlock condicons 1. Mutual exclusion At least one resource class must have non- sharable access. That is, Either one process is using that instance (and others wait), or that instance is free 2. Hold and wait At least one process is holding a resource instance, while also waigng to be granted another resource instance. (e.g., Each philosopher is holding on to their leg fork, while waigng to pick up their right fork.) 3. No preempcon Granted resources cannot be pre- empted; a resource can be released only voluntarily by the process holding it (e.g., you can't force the philosophers to drop their forks.) 4. Circular wait There must exist a circular chain of at least two processes, each of whom is waigng for a resource held by the previous one. (e.g., each Philosopher[i] is From Coffman, 1971 waigng for Philosopher[(i+1) mod 5] to drop its fork.) 24

We can break the deadlock by ensuring the circular wait does not occur Dinning Philosophers Could also force one of the Philosophers to wait at first Eliminate circular wait Number each fork in circular fashion Make each philosopher pick up lowest numbered fork first All pick up right fork, except P 4 who tries to pick up leg fork 0 Either P 0 or P 4 get fork 0 If P 0 gets it, P 4 waits for fork 0 before picking up fork 4, so P 3 eats P 3 eventually releases both forks and P 4 and P 2 eat Others eat ager P 4 and P 2 25 Cannot deadlock

Dining Philosophers demonstragon DiningPhilosphers.java Create 5 philosophers and 5 forks Each philosopher has a leg and right fork Philosopher.java Each philosopher tries to eat three meals Work up appegte (random pause) acquire leg (random pause) acquire right (random pause) eat (random pause) release right and leg forks Fork.java Keep record if available (not already acquired) Make philosopher wait if already acquired If not acquired, mark fork as acquired Release mark as not acquired and notifyall waigng 26

Another approach is to prevent hold and wait by picking up both forks atomically Dinning Philosophers Eliminate hold and wait Make picking up both forks an atomic operagons Forks no longer control their desgny as in prior code Now we lock both with a monitor Could lead to starvagon if one philosopher always picks up before another 27

Monitored version avoids deadlocks by picking up both forks atomically MonitoredDiningPhilosphers.java acquire and release moved here to get or release both forks Philosopher.java Each philosopher tries to eat three meals Uses monitor to acquire and release both forks Fork.java Simply tracks if available 28