Interprocess Communication (3)

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Ch 7 B.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
EEE 435 Principles of Operating Systems Interprocess Communication Pt II (Modern Operating Systems 2.3)
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
Interprocess Communication
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
Semaphores. Announcements No CS 415 Section this Friday Tom Roeder will hold office hours Homework 2 is due today.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
Synchronization April 14, 2000 Instructor Gary Kimura Slides courtesy of Hank Levy.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
1 Outline Processes Threads Inter-process communication (IPC) Classical IPC problems Scheduling.
CS444/CS544 Operating Systems Classic Synchronization Problems 2/26/2007 Prof. Searleman
1 Interprocess Communication Race Conditions Two processes want to access shared memory at same time.
More Synchronisation Last time: bounded buffer, readers-writers, dining philosophers Today: sleeping barber, monitors.
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
Semaphores. Readings r Silbershatz: Chapter 6 Mutual Exclusion in Critical Sections.
Midterm 1 – Wednesday, June 4  Chapters 1-3: understand material as it relates to concepts covered  Chapter 4 - Processes: 4.1 Process Concept 4.2 Process.
1 Previous Lecture Review n Concurrently executing threads often share data structures. n If multiple threads are allowed to access shared data structures.
1 Chapter 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Special Machine Instructions for Synchronization Semaphores.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
1 Interprocess Communication (IPC) - Outline Problem: Race condition Solution: Mutual exclusion –Disabling interrupts; –Lock variables; –Strict alternation.
2.3 interprocess communcation (IPC) (especially via shared memory & controlling access to it)
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Synchronization.
TANNENBAUM SECTION 2.3 INTERPROCESS COMMUNICATION3 OPERATING SYSTEMS.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
Operating Systems COMP 4850/CISG 5550 Interprocess Communication, Part II Dr. James Money.
Process Synchronization CS 360. Slide 2 CS 360, WSU Vancouver Process Synchronization Background The Critical-Section Problem Synchronization Hardware.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 22 Semaphores Classic.
Operating System Concepts and Techniques Lecture 13 Interprocess communication-2 M. Naghibzadeh Reference M. Naghibzadeh, Operating System Concepts and.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Semaphores Reference –text: Tanenbaum ch
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
Web Server Architecture Client Main Thread for(j=0;j
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion Mutexes, Semaphores.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Synchronization Background The Critical-Section Problem Peterson’s.
6.1 Silberschatz, Galvin and Gagne ©2005 Operating System Principles 6.5 Semaphore Less complicated than the hardware-based solutions Semaphore S – integer.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Synchronization Semaphores
Interprocess Communication Race Conditions
Chapter 5: Process Synchronization
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
PARALLEL PROGRAM CHALLENGES
Chapter 5: Process Synchronization – Part II
Chapter 5: Process Synchronization
Chapter 5: Process Synchronization
CSE451 Basic Synchronization Spring 2001
Lecture 13: Producer-Consumer and Semaphores
Topic 6 (Textbook - Chapter 5) Process Synchronization
Process Synchronization
Synchronization Hank Levy 1.
Critical section problem
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
Lecture 13: Producer-Consumer and Semaphores
Synchronization Hank Levy 1.
CSE 153 Design of Operating Systems Winter 19
Chapter 7: Synchronization Examples
CSE 153 Design of Operating Systems Winter 2019
FIRST SOLUTION Producer Process Consumer Process
Synchronization CSE 2431: Introduction to Operating Systems
Presentation transcript:

Interprocess Communication (3) Operating Systems Interprocess Communication (3)

Producer/Consumer Bounded Buffer Producer puts items into a buffer Consumer removes items from buffer Producer issue: attempts to put an item in a full buffer Consumer issue: attempts to remove an item from an empty buffer

Producer/Consumer Model 1 prod_cons1() { Global int N = 100; int count = 0; } parbegin producer(); consumer(); parend producer() itemType item; while(1) if (count == N) sleep(); produce(); ++count; if (count == 1) wakeup(consumer); consumer() int item; if (count == 0) --count; if (count == (N – 1)) wakeup(producer) c

Access to Count is unconstrained buffer is empty consumer tests count context-switch before sleep producer puts an item in the buffer increments count to 1 tries to wakeup consumer, but consumer is not asleep produces goes on filling the buffer then goes to sleep consumer runs and goes to sleep Could be solved with either peterson or tsl

Spinlock Semaphore ADT Proposed by Dijkstra wait(int* S) //frequently called “down” { while( *S<= 0;) //item is in CS *S--; } signal(int* S) //frequently called “up” { *S++; } Key Ideas Apart from initialization, S is only modifiable by wait and signal All modifications to S in wait an signal are done without interruption 3. Testing S is done without interruption

N-Process Example N_Process() { Global int s = 1; } parbegin proc0(); parend //All N processes look like //this proc_0() while(1) wait(&s); cs(); signal(&s); proc0 runs and calls wait s == 1, so s is decremented to 0 Enter CS proc1, calls wait, fails test and sits in loop proc2, calls wait, fails test and sits in loop proc0 runs, finishes CS, calls signal, increments s proc2 runs, passes while test, decrements s, leaves down, enters CS

SempAhores can Synchronize processes. Proc0 before proc1 { Global int s = 0; } parbegin proc0(); proc1(); parend Proc0() cs(); signal(&s); Proc1() wait(&s); cs()

PROC_0 PRODUCES X FOR PROC_1 TO CONSUME PROC_1 PRODUCES Y FOR PROC_0 TO CONSUME synch() { Global int s1 = s2 = 0; itemType x, y; } parbegin proc0(); proc1(); parend }1 proc_0() while(1) x = produce(); signal(&s1); wait(&s2) consume(y); proc_1() { wait(s1); consume(x); y = produce(); signal(s2) Demonstrate with a table: s1, s2, x y

Problem with the Semaphore as defined? Busy Wait SOLUTION: COUNTING SEMAPHORE

Counting Semaphore Requires Linked List of processes typedef struct { int value; struct process *list; //a list of processes } semaphore

Wait and signal wait(semaphore* S) { S → value--; if (S → value < 0) { add (pid) S → list; block(pid); } } signal(semaphore* S) { S → value++; if (S → value <= 0) { pid = remove(S → list); wakeup(pid); } } “It is critical that semaphore operations be executed atomically. We must guarantee that no two process can execute wait() and signal() on the same semaphore at the same time.” (Silberschatz, p. 216). With single processors, we disable interrupts. With mulitiple processors, it becomes necessary to reintroduce busy-wait. Message passing is the answer.

N Process Semaphore Example cnt_sem() { semaphore s1; s1.value = 1 parbegin { proc0(&s1) ... proc1(&s1); } parend procj(semaphor* s1) { while(1) { wait(s1); crit_sect(); signal(s1); }

Scenario 1. proc0() runs, calls down: value == 0, enters CS 2. proc1() runs, calls down: value == -1, fails test and blocks 3. proc2() runs, calls down: value == -2, fails test and blocks] 4. proc0() runs, finished CS, calls up: value == -1, removes p1 from sleep list, wakes up p1 lst p1 lst p1 p2 lst p1

Producer-Consumer With Counting Semaphores Recall Producer/Consumer required 1 variables (count) and a buffer in which to store items produces or consumed. Both must be protected Solution with three semaphores empty: counts empty buffer slots, initially N full: counts full buffer slots, initially 0 mutex: controls access to buffer, initially 1

Producer-Consumer Model 2 prod_cons2() { Global sem mutex; sem empty; semfull: mutex.value = 1; empty.value = 100; full.value = 0; } parbegin { producer(); consumer(); parend producer() while(1) wait(&empty); wait(&mutex); produce(); signal(&mutex); signal(&full); consumer() wait(&full); consume(); signal(&empty);

Scenario 1 consumer runs value == -1, blocks on full producer runs dec empty, dec mutex, enters cs, inc mutex, I inc full full.s == 0, wakes up consumer

Suppose full.s == 98, empty.s == 2, mutex.s == 1 producer runs: dec empty (so empty.s == 1), dec mutex (so mutex.s == 0), enters cs consumer runs: dec full (so full.s == 97), dec mutex (so mutex.s == -1) consumer blocks on mutex producer runs: inc mutex (so mutex.s == 0), wakes up consumer, inc full (so full.s == 98) consumer runs: enters cs, inc mutex (so mutex.s == 1), inc empty (so empty.s == 2) Semphore values: full.s == 98, empty.s == 2, mutex.s == 1 Both Producer and consumer have run to completion. Semaphore values are as they were in the beginning

A Trap Suppose in Producer Order of wait on mutx and empty switched

(more or less) Correct solutions Peterson software two processes busy-wait TSL hardware N processes Spinlock Semaphore Hardware N processes busy-wait Counting Semaphore sleep/wakeup Limited to single processors without busy- wait.

Building a Model of Producer/Consumer Primitives pipes: direct communication link between two linux processes semaphore system calls in linux