Coordination 6.894 Lecture 5.

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

Previously… Processes –Process States –Context Switching –Process Queues Threads –Thread Mappings Scheduling –FCFS –SJF –Priority scheduling –Round Robin.
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.
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.
Interprocess Communication
Synchronization. Shared Memory Thread Synchronization Threads cooperate in multithreaded environments – User threads and kernel threads – Share resources.
Operating Systems ECE344 Ding Yuan Synchronization (I) -- Critical region and lock Lecture 5: Synchronization (I) -- Critical region and lock.
Threading Part 2 CS221 – 4/22/09. Where We Left Off Simple Threads Program: – Start a worker thread from the Main thread – Worker thread prints messages.
1 CS318 Project #3 Preemptive Kernel. 2 Continuing from Project 2 Project 2 involved: Context Switch Stack Manipulation Saving State Moving between threads,
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Jonathan Walpole Computer Science Portland State University
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts, Amherst Operating Systems CMPSCI 377 Lecture.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Synchronization CSCI 444/544 Operating Systems Fall 2008.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
CS510 Concurrent Systems Introduction to Concurrency.
Implementing Synchronization. Synchronization 101 Synchronization constrains the set of possible interleavings: Threads “agree” to stay out of each other’s.
Chapter 28 Locks Chien-Chung Shen CIS, UD
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Univ. of TehranDistributed Operating Systems1 Advanced Operating Systems University of Tehran Dept. of EE and Computer Engineering By: Dr. Nasser Yazdani.
CPS110: Implementing threads Landon Cox. Recap and looking ahead Hardware OS Applications Where we’ve been Where we’re going.
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.
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
CSE 153 Design of Operating Systems Winter 2015 Midterm Review.
1 Previous Lecture Overview  semaphores provide the first high-level synchronization abstraction that is possible to implement efficiently in OS. This.
Implementing Lock. From the Previous Lecture  The “too much milk” example shows that writing concurrent programs directly with load and store instructions.
CS510 Concurrent Systems Jonathan Walpole. Introduction to Concurrency.
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
CS162 Section 2. True/False A thread needs to own a semaphore, meaning the thread has called semaphore.P(), before it can call semaphore.V() False: Any.
December 1, 2006©2006 Craig Zilles1 Threads & Atomic Operations in Hardware  Previously, we introduced multi-core parallelism & cache coherence —Today.
CSE 120 Principles of Operating
Thread Synchronization
CS703 – Advanced Operating Systems
Background on the need for Synchronization
Synchronization.
Atomic Operations in Hardware
Atomic Operations in Hardware
143a discussion session week 3
Lecture 12: Peterson’s Solution and Hardware Support
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
Module 7a: Classic Synchronization
Jonathan Walpole Computer Science Portland State University
COT 5611 Operating Systems Design Principles Spring 2012
UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department
Lecture 2 Part 2 Process Synchronization
Implementing Mutual Exclusion
Implementing Mutual Exclusion
Kernel Synchronization II
Lecture 12: Peterson’s Solution and Hardware Support
Lecture 13: Producer-Consumer and Semaphores
Lecture 11: Mutual Exclusion
CSE 451: Operating Systems Autumn 2004 Module 6 Synchronization
CSE 451: Operating Systems Autumn 2003 Lecture 7 Synchronization
CSE 451: Operating Systems Autumn 2005 Lecture 7 Synchronization
CSE 451: Operating Systems Winter 2004 Module 6 Synchronization
CSE 451: Operating Systems Winter 2003 Lecture 7 Synchronization
CSE 153 Design of Operating Systems Winter 19
CSE 153 Design of Operating Systems Winter 2019
CS333 Intro to Operating Systems
Chapter 6: Synchronization Tools
CSE 542: Operating Systems
Presentation transcript:

Coordination 6.894 Lecture 5

Why Coordinate? Critical section: What are sources of interruption? Must execute atomically, without interruption. Atomicity usually only w.r.t. other operations on the same data structures. What are sources of interruption? Hardware interrupts, UNIX signals. Thread pre-emption. Interleaving of multiple CPUs.

Tools for Atomicity (1) If this worked, we would be done: TestAndSet(int *addr){ int old = *addr; *addr = 1; return(old); } insert(…){ while(TestAndSet(&locked) == 1) ; /* critical section goes here */ locked = 0; }

Tools for Atomicity (2) Turn off interrupts in TAS to avoid race. Prevents pre-emption via real-time clock. Only in the kernel, only on a uniprocessor. Kernel emulation of TestAndSet. Only on a uniprocessor. Test-And-Set-Locked hardware support.

Test-And-Set-Locked Instruction Single instruction to do this: int old = *addr; *addr = 1; return(old); The hardware locks the memory system to keep the two sub-operations atomic. TSL lets us build more complex atomic sequences. See Example 3 for a simple one.

Problems with TSL Operates at motherboard speeds, not CPU. Much slower than cached load or store. Prevents other use of the memory system. Interferes with other CPUs and DMA. Silly to spin in TSL on a uniprocessor. Add a thread_yield() after every TSL.

Locks Aren’t Enough Summary of code Example 4: What’s the problem? Consumer: If(input isn’t ready) sleep(); Producer: If(consumer is waiting) wake it up; What’s the problem? Can we solve the problem with locks alone?

Sequence Coordination Need to avoid races between decision to sleep and actual sleep(). Can’t hold lock while sleeping. Need the thread scheduler to help us release the lock. Common abstraction: condition variables. Code Examples 5 and 6.

Condition Variable Rules Hold the lock while calling wait(). Hold the lock while calling signal(). wait() acquires the lock before returning.