Concurrency Motivation 1: Mutual Exclusion

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

1 Chapter 5 Concurrency: Mutual Exclusion and Synchronization Principals of Concurrency Mutual Exclusion: Hardware Support Semaphores Readers/Writers Problem.
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)
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
1 Semaphores and Monitors CIS450 Winter 2003 Professor Jinhua Guo.
Informationsteknologi Wednesday, September 26, 2007 Computer Systems/Operating Systems - Class 91 Today’s class Mutual exclusion and synchronization 
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
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.
Modified from Sommerville’s originalsSoftware Engineering, 5th edition. Chapter 15 Slide 1 Function-oriented design Software Engineering Ian Sommerville.
Semaphores. Announcements No CS 415 Section this Friday Tom Roeder will hold office hours Homework 2 is due today.
Language Support for Concurrency. 2 Common programming errors Process i P(S) CS P(S) Process j V(S) CS V(S) Process k P(S) CS.
Semaphores CSCI 444/544 Operating Systems Fall 2008.
Function-oriented design portions ©Ian Sommerville 1995 Design with functional units which transform inputs to outputs.
Concurrency - 1 Tasking Concurrent Programming Declaration, creation, activation, termination Synchronization and communication Time and delays conditional.
Concurrent computations n Concurrent units that executes in parallel n Physical parallelism n Logical parallelism n Parallel abstract machine n How does.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
University of Pennsylvania 9/28/00CSE 3801 Concurrent Programming (Critical Regions, Monitors, and Threads) CSE 380 Lecture Note 6 Insup Lee.
Semaphores and Bounded Buffer Andy Wang Operating Systems COP 4610 / CGS 5765.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 15Slide 1 Function-oriented design u Design with functional units which transform inputs.
1 Concurrency Architecture Types Tasks Synchronization –Semaphores –Monitors –Message Passing Concurrency in Ada Java Threads.
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.
Chap 6 Synchronization. Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
ICS 313: Programming Language Theory Chapter 13: Concurrency.
PZ12B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ12B - Synchronization and semaphores Programming Language.
Synchronization and semaphores Programming Language Design and Implementation (4th Edition) by T. Pratt and M. Zelkowitz Prentice Hall, 2001 Section
1 Lecture 8: Concurrency: Mutual Exclusion and Synchronization(cont.) Advanced Operating System Fall 2009.
Chapter 12, Slide 1 Concurrency Motivation 1: Mutual Exclusion  John and Mary share a bank acc't  withdraw x = copy balance to local machine subtract.
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
Concurrency in Shared Memory Systems Synchronization and Mutual Exclusion.
Process Synchronization. Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Chapter 5 Concurrency: Mutual Exclusion and Synchronization Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee.
Process Synchronization
Process Synchronization: Semaphores
PARALLEL PROGRAM CHALLENGES
Background on the need for Synchronization
Chapter 5: Process Synchronization
Operating Systems CMPSC 473
Chapter 5: Process Synchronization
5-High-Performance Embedded Systems using Concurrent Process (cont.)
Concurrency: Mutual Exclusion and Synchronization
Topic 6 (Textbook - Chapter 5) Process Synchronization
Semaphore Originally called P() and V() wait (S) { while S <= 0
Process Synchronization
Module 7a: Classic Synchronization
Synchronization Hank Levy 1.
Critical section problem
CSE 451: Operating Systems Winter Module 8 Semaphores and Monitors
Subject : T0152 – Programming Language Concept
CSE 451: Operating Systems Autumn Lecture 8 Semaphores and Monitors
CSE 451: Operating Systems Autumn Lecture 7 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
Synchronization Hank Levy 1.
Synchronization: Monitors
CSE 153 Design of Operating Systems Winter 19
Chapter 6: Synchronization Tools
CSE 451: Operating Systems Winter Module 7 Semaphores and Monitors
Synchronization and semaphores
Review The Critical Section problem Peterson’s Algorithm
Presentation transcript:

Concurrency Motivation 1: Mutual Exclusion John and Mary share a bank acc't withdraw x = copy balance to local machine subtract x give out $$ write back (balance - x) Suppose John & Mary each withdraw $100 at the same time, from different machines: John copies balance Mary copies balance John gets $100 Mary gets $100 John writes back (balance - 100) Mary writes back (balance - 100) New balance = balance - 100!

Mutual Exclusion (continued) Use a variable to restrict access to the account: type gate = {open, closed}; var access: gate; John/Mary: while access = open do; access := closed; withdraw $$; access := open But what if John : test, access = open Mary : test, access = open -- before John has closed it John : set access = closed Mary : set access = closed John: withdraw $$ Mary: withdraw $$ etc. Problem: test/set of access is divisible

The Producer/Consumer Model Motivation 2: Synchronization Producer / Consumer: Producer makes items, places them in n-element buffer Consumer removes items from buffer Important: don't put items in full buffer don't take items from empty buffer Suppose a buffer counter t is incremented by producer and decremented by consumer: read t into private register update value of t locally write back to t

Semaphores (Dijkstra 1965) A semaphore is a data object that can assume an integer value and can be operated on by primitives P and V. P(s) = if s > 0 then s := s - 1 else suspend current process; V(s) = if there is a process suspended on s then wake it up else s := s + 1; Important: P and V are indivisible instructions. P: proberen (to try) or passeren (to pass) V: verhogen (to increase) or vrygeren (to release)

Solving Bank Problem with Semaphores var mutex : semaphore := 1; John: P(mutex); withdraw $$; V(mutex); Mary:

General Producer/Consumer Model semaphore mutex := 1, -- availability control in := 0, -- # of things in buffer spaces := n; -- # of empty spaces in buffer process producer repeat produce thing; P(spaces); -- wait for buffer space P(mutex); -- wait for buffer availability put thing in buffer; V(mutex); -- free buffer V(in); -- increase # of items in buffer forever process consumer P(in); -- wait until something in buffer take thing from buffer; V(mutex); -- free buffer V(spaces); -- increase # free spaces in buffer

About Semaphores Each semaphore has way to suspend processes (use process queue) policy for selecting process to wake up. One semaphore per synchronization condition, not per resource. Low level, may be tricky and tedious to use. Deadlock quite possible.

Monitors (Brinch Hansen & Hoare '73-'74) • ADTs in a concurrent environment used in Concurrent Pascal, Modula • Instance of a monitor => shared resource • Monitors are passive: data + proc defs + init code • Active processes use monitors • Mutual exclusion of access to monitor guaranteed by system

Implementing a Producer/Consumer Buffer with Monitors main queue (calls to append and remove) sender . . . receiver . buffer (type fifostorage)

Monitor Implementation type fifostorage = monitor var contents: array [1. .n] of integer; -- data tot: 0. .n; -- count of items in buffer in, out: 1. .n; -- “pointers” to buffer cells sender, receiver: queue; procedure entry append (item: integer); -- procedures begin if tot = n then delay (sender); contents[in] := item; in := (in mod n) + 1; tot := tot + 1; continue (receiver) end; procedure entry remove (var item: integer); if tot = 0 then delay (receiver); item := contents[out]; out := (out mod n) + 1; tot := tot - 1; continue (sender) begin -- initialization code tot := 0; in := 1; out := 1 end

Monitor Implementation (continued) type producer = process (storage: fifostorage); var element: integer; begin cycle . . . storage.append (element); end end; type consumer = process (storage: fifostorage); var datum: integer; storage.remove (datum); var meproducer: producer; youconsumer: consumer; buffer: fifostorage; begin -- start everything init buffer, meproducer (buffer), youconsumer (buffer)

Monitors (continued) for cooperation, use delay and continue: delay -- takes name of queue and suspends executing process on that queue continue -- takes name of queue and reactivates a suspended process on that queue. In both cases, active process releases lock on monitor.

Rendezvous (Ada) Ada concurrent units: tasks No active/passive distinction; shared resource is represented by a task. Entry into task is via an accept statement, often inside a select, i.e., {when <condition> =>} accept <entryname> (<params>) do <entry body>; end; To other process, task entry call is (and looks) just like any procedure except it's only carried out when the task owning the entry executes the corresponding accept. Rendezvous: entry has been invoked, and task w/entry declaration has executed accept. Suspension: caller invokes entry when task not in accept, or task executes accept when no other task has called entry

Ada Rendezvous (continued) Accepts: Alternatives with true when condition are marked open. (Those without conditions are always open.) Open entries for which an entry call has already been issued are marked available. Any available alternative may be selected (nondeterminism). Open alternatives but no available alternatives => task suspends until one becomes available. No open alternatives => error. Only one entry can be accepted at a time

Either-Or Rendezvous Task task body Data_collector is begin select -- if data is available for processing, process it -- otherwise execute the else part of the select statement accept Put_data ( Sensor_in: SENSOR_VALUE) do Process_data (Sensor_in) ; end Put_data ; else -- execute Self_test rather than wait for data Self_test ; end select ; end Data_collector ;

Implementing Producer/Consumer with Ada Rendezvous task buffer_handler is entry append (item: in integer); entry remove (item: out integer); end; task body buffer_handler is n: constant integer := 20; -- buffer size contents: array (1. .n) of integer; in, out: integer range 1. .n := 1; -- “pointers” into buffer tot: integer range 0. .n := 0; -- # of items currently in buffer begin loop select when tot < n => -- buffer not full accept append (item: in integer) do contents(in) := item; in := (in mod n) + 1; tot := tot + 1; or when tot > 0 => -- buffer not empty accept remove (item: out integer) do item := contents (out); out := (out mod n) + 1; tot := tot - 1; end select; end loop; end buffer_handler; PRODUCER CONSUMER loop loop produce new value V; buffer_handler.remove (V); buffer_handler.append (V); consume V; exit when V => end of stream; exit when V => end of stream; end loop; end loop;

Ada Sequence Counter task Counter is entry Add (N: NATURAL) ; entry Subtract (N: NATURAL) ; entry Put_value (N: NATURAL) ; entry Get_value (N: out NATURAL) ; end Counter ; task body Counter is Value: NATURAL := 0 ; begin loop select accept Add (N: NATURAL) do Value := Value + N ; end Add ; or accept Subtract (N: NATURAL) do Value := Value - N ; end Subtract ; accept Put_value (N: NATURAL) do Value := N ; end Put_value ; accept Get_value (N: out NATURAL) do N := Value ; end Get_value ; end select ; end loop ;

Ada Transponder task type Transponder is entry Give_position (Pos: POSITION ) ; end Transponder ; task body Transponder is Current_position: POSITION ; C1, C2: Satellite.COORDS ; loop select accept Give_position (Pos: out POSITION) do Pos:= Current_position ; end Give_position ; else C1 := Satellite1.Position ; C2 := Satellite2.Position ; Current_position := Navigator.Compute (C1, C2) ; end select ; end loop ;

Concurrent Office IR System procedure Office_system is task Get_command ; task Process_command is entry Command_menu ; entry Display_indexes ; entry Edit_qualifier ; -- Additional entries here. -- One for each command end Process_commands ; task Output_message is entry Message_available ; end Output_message ; task Workspace_editor is entry Enter ; entry Leave ; end Workspace_editor ; (to be continued)

Concurrent Office IR System - II task body Get_command is begin loop Cursor_position := Get_cursor_position ; exit when cursor positioned in workspace or (cursor positioned over menu and button pressed) Display_cursor_position ; end loop ; if In_workspace (Cursor_position) then Workspace_editor.Enter ; elsif In_command_menu (Cursor_position) then Process_command.Command_menu ; elsif In_Known_indexes (Cursor_position) then Process_command.Display_indexes ; elsif In_Current_indexes (Cursor_position) then ... Other commands here end Get_command ;

Concurrent Office IR System - III task body Process_command is Command: COMMAND.T ; Index: INDEX.T ; begin Workspace_editor.Leave ; loop accept Command_menu do Display_command_menu ; Get_menu_selection (Command) ; Execute_menu_command (Command) ; end Command_menu; accept Display_indexes do Display_current_indexes ; Get_index_selection (Index) ; end Display_indexes; ... Other commands here end Office_system ;

Sequenced Rendezvous Actions For the case where actions are to be in a strict sequence task body Thermocouple is begin accept Get_temperature (T: in out TEMPERATURE) do -- code here to interrogate the hardware end Get_temperature ; accept Calibrate (T: TEMPERATURE) do -- code here to calibrate the thermocouple end Calibrate ; accept Disconnect do -- code to implement a hardware shutdown end Disconnect ; end Thermocouple ;