Concurrency: Mutual Exclusion and Synchronization

Slides:



Advertisements
Similar presentations
COMMUNICATING SEQUENTIAL PROCESSES C. A. R. Hoare The Queen’s University Belfast, North Ireland.
Advertisements

1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Ch4. Processes Process Concept (1) new waiting terminate readyrunning admitted interrupt exit scheduler dispatch I/O or event completion.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Chapter 6 Process Synchronization Bernard Chen Spring 2007.
Chapter 6: Process Synchronization
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles Seventh Edition By William Stallings.
Concurrency: mutual exclusion and synchronization Slides are mainly taken from «Operating Systems: Internals and Design Principles”, 8/E William Stallings.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles Seventh Edition By William Stallings.
Lecture 5: Concurrency: Mutual Exclusion and Synchronization.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
Day 14 Concurrency. Software approaches Programs must be written such that they ensure mutual exclusion. Petersons and Dekkers (Appendix B)
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Enforcing Mutual Exclusion, Semaphores. Four different approaches Hardware support Disable interrupts Special instructions Software-defined approaches.
Enforcing Mutual Exclusion Message Passing. Peterson’s Algorithm for Processes P0 and P1 void P0() { while( true ) { flag[ 0 ] = false; /* remainder */
Concurrency: Mutual Exclusion and Synchronization Why we need Mutual Exclusion? Classical examples: Bank Transactions:Read Account (A); Compute A = A +
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and 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.
6/16/2015 Chapter Eight Process Synchronisation. Index Objectives Concurrent processes and Asynchronous concurrent processes Process synchronisation Mutual.
1 Semaphores Special variable called a semaphore is used for signaling If a process is waiting for a signal, it is suspended until that signal is sent.
Concurrency: Mutual Exclusion, Synchronization, Deadlock, and Starvation in Representative Operating Systems.
Process Synchronization
OS Fall’02 Concurrency Operating Systems Fall 2002.
Synchronization Solutions
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
1 Chapter 5 Concurrency. 2 Concurrency 3 4 Mutual Exclusion: Hardware Support Test and Set Instruction boolean testset (int *i) { if (*i == 0) { *i.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings 1.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago.
Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago Polytechnic,
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Dave Bremer Otago.
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.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 7: Process Synchronization Background The Critical-Section Problem Synchronization.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Synchronization Methods in Message Passing Model.
Process Synchronization Tanenbaum Ch 2.3, 2.5 Silberschatz Ch 6.
Synchronizing Threads with Semaphores
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
1 Lecture 8: Concurrency: Mutual Exclusion and Synchronization(cont.) Advanced Operating System Fall 2009.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Operating System Chapter 5. Concurrency: Mutual Exclusion and Synchronization Lynn Choi School of Electrical Engineering.
Synchronicity II Introduction to Operating Systems: Module 6.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Operating System Concepts and Techniques Lecture 14 Interprocess communication-3 M. Naghibzadeh Reference M. Naghibzadeh, Operating System Concepts and.
Semaphores Chapter 6. Semaphores are a simple, but successful and widely used, construct.
Gokul Kishan CS8 1 Inter-Process Communication (IPC)
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
Message passing model. buffer producerconsumer PRODUCER-CONSUMER PROBLEM.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Semaphores Synchronization tool (provided by the OS) that does not require busy waiting. Logically, a semaphore S is an integer variable that, apart from.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization
Background on the need for Synchronization
Chapter 5: Process Synchronization
Concurrency: Mutual Exclusion and Synchronization
Chapter 5: Process Synchronization
Concurrency: Mutual Exclusion and Synchronization
Semaphores Chapter 6.
Presentation transcript:

Concurrency: Mutual Exclusion and Synchronization Chapter 5 (Part 3)

Semaphores Special variable called a semaphore is used for signaling If a process is waiting for a signal, it is suspended until that signal is sent Wait and signal operations cannot be interrupted Queue is used to hold processes waiting on the semaphore

Definition of Semaphores (1) type semaphore = record count: integer; queue: list of process end; var s: semaphore;

Definition of Semaphores (2) Wait(s): s.count := s.count -1; if s.count < 0 then begin place this process in s.queue; block this process end; Signal(s): s.count := s.count + 1; if s.count <= 0 remove a process P from s.queue; place process P on ready list

Question 1 (1) Consider the new definition of semaphores (next slide). Compare this set of definitions with that of previous (old) definition. Note one difference: with the new definition, a semaphore can never take on a negation value. Is there any difference in the effect of the two sets of definitions when used in program. That is, could you substitute one set for the other without altering the meaning of the program?

Question 1 (2) Wait(s): if s.count > 0 then s.count := s.count - 1 else begin place this process in s.queue; block this process end; Signal(s): begin if there is at least one process suspended on semaphores then begin remove a process P from s.queue; place process P on ready list end else s.count := s.count + 1

Definition of Binary Semaphores (1) type binary semaphore = record count: (0, 1); queue: list of process end; var s: binary semaphore;

Definition of Binary Semaphores (2) WaitB(s): if s.value = 1 then s.count := 0; else begin place this process in s.queue; block this process end; SignalB(s): if s.queue is empty then s.value := 1; remove a process P from s.queue; place process P on ready list

Producer/Consumer Problem (1) One or more producers are generating date and placing these in a buffer A single consumer is taking items out of the buffer one at time Only one producer or consumer may access the buffer at any one time Two semaphores are used one to represent the amount of items in the buffer one to signal that it is all right to use the buffer

Producer Function - Producer/Consumer Problem (2) repeat produce item v; b[in] := v; in := in + 1 forever;

Consumer Function - Producer/Consumer Problem (3) repeat while in <= out do { nothing }; w := b[out]; out := out + 1; consume item w forever;

Infinite Buffer for Producer/Consumer Problem - Producer/Consumer Problem (4) . . . . b[1] b[5] out in Note: shade area indicates portion of buffer that is occupied

Using Binary Semaphores - Producer/Consumer Problem (5) program producerconsumer; var n: integer; s: (*binary*) semaphore (:=1); delay: (*binary*) semaphore(:=0); … ... begin (*main program *) n:= 0; parbegin producer; consumer parend end.

Using Binary Semaphores - Producer/Consumer Problem (6) procedure producer procedure consumer; var m:integer;(*local var*) begin begin waitB(delay) repeat repeat produce; waitB(s); waitB(s); take; append; n:=n-1; n:=n+1; m:=n; if n=1 signalB(s); then signalB(delay); consume; signalB(s) if m=0 then waitB(delay) forever forever end; end;

Question 2 (1) Consider the solution to the infinite-buffer produce/consumer problem given before. Suppose we have the (common) case in which the producer and consumer are running at roughly the same speed. The scenario could be as follow: Producer: append; signal; produce; ...; append; signal; produce;.. Consumer: consume; ….; take; wait; consume; …; take; wait; … The producer always manages to append a new element to the buffer and signal during the consumption of the previous element by the consumer. The procedure is always appending to an empty buffer and the consumer is always taking the sole item in the buffer. Although the consumer never blocks on the semaphore, a large number of calls to the semaphore mechanism is made, creating considerable overhead. Construct a new program that will be more efficient under these circumstances.

Using Counting Semaphores (1) program producerconsumer; var n: semaphore (:=0); s: semaphore (:=1); ... begin (*main program *) parbegin producer; consumer parend end.

Using Counting Semaphores (2) procedure producer procedure consumer; begin begin repeat repeat produce; wait(n); wait(s); wait(s); append; take; signal(s) signal(s); signal(n) consume; forever forever end; end;

Producer with Circular Buffer repeat produce item v; while ( (in + 1) mod n = out) do { nothing }; b[in] := v; in := (in + 1) mod n forever;

Consumer with Circular Buffer repeat while in = out do { nothing }; w := b[out]; out := (out + 1) mod n; consume item w forever;

Monitors Software procedures Only one process may be executing in the monitor at a time. Other processes are suspended while waiting for the monitor Processes may be suspended while in the monitor

Structure of a Monitor Queue of Entering Processes Monitor Waiting Area Entrance MONITOR condition c1 Local Data cwait(c1) Condition Variables …... Procedure 1 Condition cn …... cwait(cn) Procedure n Urget Queue csignal Initialization Code Exit

Message Passing Enforce mutual exclusion Exchange information send (destination, message) receive (source, message)

Message Passing - Synchronization Sender and receiver may or may not be blocking (waiting for message) Blocking send, blocking receive both sender and receiver are blocked until message is delivered

Message Passing - Synchronization Nonblocking send, blocking receive sender continues processing such as sending messages as quickly as possible receiver is blocked until the requested message arrives Nonblocking send, nonblocking receive

Addressing Direct addressing send primitive includes a specific identifier of the destination process receive primitive could know ahead of time which process a message is expected receive primitive could use source parameter to return a value when the receive operation has been performed

Addressing Indirect addressing messages are sent to a shared data structure consisting of queues queues are called mailboxes one process sends a message to the mailbox and the other process picks up the message from the mailbox

General Message Format Message Type Destination ID Header Source ID Message Length Control Info. Message Contents Body

Queuing Discipline The simplest queuing discipline is first-in-first-out (FIFO). Pipe or named pipe can be use for queuing discipline.