Lecture 12: Peterson’s Solution and Hardware Support

Slides:



Advertisements
Similar presentations
1 Interprocess Communication 1. Ways of passing information 2. Guarded critical activities (e.g. updating shared data) 3. Proper sequencing in case of.
Advertisements

Global Environment Model. MUTUAL EXCLUSION PROBLEM The operations used by processes to access to common resources (critical sections) must be mutually.
Chapter 2 Processes and Threads
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.
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.
Mutual Exclusion.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
CSC 322 Operating Systems Concepts Lecture - 8: by Ahmed Mumtaz Mustehsan Special Thanks To: Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall,
Interprocess Communication
Cpr E 308 Spring 2004 Recap for Midterm Introductory Material What belongs in the OS, what doesn’t? Basic Understanding of Hardware, Memory Hierarchy.
CS444/CS544 Operating Systems Synchronization 2/21/2006 Prof. Searleman
EEE 435 Principles of Operating Systems Interprocess Communication Pt I (Modern Operating Systems 2.3)
Interprocess Communication
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
1 CS 333 Introduction to Operating Systems Class 4 – Synchronization Primitives Semaphores Jonathan Walpole Computer Science Portland State University.
Jonathan Walpole Computer Science Portland State University
1 Outline Processes Threads Inter-process communication (IPC) Classical IPC problems Scheduling.
1 Interprocess Communication Race Conditions Two processes want to access shared memory at same time.
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.
Implementing Synchronization. Synchronization 101 Synchronization constrains the set of possible interleavings: Threads “agree” to stay out of each other’s.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Introduction to Concurrency.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
Mutual Exclusion. Readings r Silbershatz: Chapter 6.
Cpr E 308 Spring 2004 Real-time Scheduling Provide time guarantees Upper bound on response times –Programmer’s job! –Every level of the system Soft versus.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts Essentials – 9 th Edition Chapter 5: Process Synchronization.
CY2003 Computer Systems Lecture 04 Interprocess Communication.
Thread Implementations; MUTEX Reference on thread implementation –text: Tanenbaum ch. 2.2 Reference on mutual exclusion (MUTEX) –text: Tanenbaum ch
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
1 Processes and Threads Part II Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Implementing Lock. From the Previous Lecture  The “too much milk” example shows that writing concurrent programs directly with load and store instructions.
Operating System Concepts and Techniques Lecture 13 Interprocess communication-2 M. Naghibzadeh Reference M. Naghibzadeh, Operating System Concepts and.
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion Mutexes, Semaphores.
Interprocess Communication Race Conditions
Dave Eckhardt Synchronization (2) Dave Eckhardt
Chapter 5: Process Synchronization
Process Synchronization - I
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
Peculiarity of Peterson’s Solution to Process Synchronization
Lecture 16: Readers-Writers Problem and Message Passing
Jonathan Walpole Computer Science Portland State University
Thread Implementations; MUTEX
Lecture 2 Part 2 Process Synchronization
Critical section problem
Coordination Lecture 5.
Global Environment Model
Grades.
Implementing Mutual Exclusion
Chapter 6: Process Synchronization
Implementing Mutual Exclusion
Lecture 12: Peterson’s Solution and Hardware Support
Lecture 16: Readers-Writers Problem and Message Passing
Lecture 13: Producer-Consumer and Semaphores
Thread Implementations; MUTEX
Lecture 11: Mutual Exclusion
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Chapter 6: Synchronization Tools
Interprocess Communication & Synchronization
Process/Thread Synchronization (Part 2)
Process Management -Sheetal Thapaliya (Compiled for CSIT
Presentation transcript:

Lecture 12: Peterson’s Solution and Hardware Support

Review: Mutual Exclusion Critical region Disabling interrupts Strict alternation

In this lecture Mutual exclusion solutions Peterson’s solution Hardware support

General structure enter_region(); critical_region(); leave_region();

Peterson’s Solution (1981)

Hardware Support: TSL New Instruction: TSL R, Lock TSL = “Test and Set Lock” R = register, Lock = memory location Atomically (atomic = nothing can interfere) - Read Lock into R - Store a non-zero value into Lock

Mutual Exclusion using TSL /* set lock to non-zero, proceed if it was 0 earlier */ enter_region: TSL Reg, Lock /* set Lock to 1, copy old value of Lock into Reg*/ If (Reg != 0) then /* not the first to set to zero */ Jump enter_region /* try again */ return leave_region: Lock = 0

Alternative to TSL: XCHG /* set lock to non-zero, proceed if it was 0 earlier */ enter_region: Reg = 1 XCHG Reg, Lock /* swap contents of Reg and Lock */ If (Reg != 0) then /* not the first to set to zero */ Jump enter_region /* try again */ return leave_region: Lock = 0

Problem Busy waiting Possible solution: Yield to another thread if unable to lock first time

Eliminate Busy Waiting /* set lock to non-zero, proceed if it was 0 earlier */ enter_region: TSL Reg, Lock /* set Lock to 1, copy old value of Lock into Reg*/ If (Reg != 0) then /* not the first to set to zero */ { thread_yield() ; /* let somebody else run */ Jump enter_region /* try again */ } return leave_region: Lock = 0

Summary of mutual exclusion solutions Software solution Disabling interrupts Single processor only Use in kernel mode Strict alternation Strict ordering Busy waiting Peterson’s solution Hardware solution TSL/XCHG Works on multiprocessors

Avoiding Busy Waiting If a process cannot enter critical region, the process calls sleep() to give up CPU. A process wakes up another process using wakeup()

Review: Mutual Exclusion using TSL /* set lock to non-zero, proceed if it was 0 earlier */ enter_region: TSL Reg, Lock /* set Lock to 1, copy old value of Lock into Reg*/ If (Reg != 0) then /* not the first to set to zero */ Jump enter_region /* try again */ return leave_region: Lock = 0

TSL without busy waiting /* set lock to non-zero, proceed if it was 0 earlier */ enter_region: TSL Reg, Lock /* set Lock to 1, copy old value of Lock into Reg*/ If (Reg != 0) then /* not the first to set to zero */ { sleep() Jump enter_region /* try again */ return leave_region: Lock = 0 wakeup(process_id)