ICS143A: Principles of Operating Systems Lecture 15: Locking

Slides:



Advertisements
Similar presentations
More on Semaphores, and Classic Synchronization Problems CSCI 3753 Operating Systems Spring 2005 Prof. Rick Han.
Advertisements

Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CSE 451: Operating Systems Winter 2012 Synchronization Mark Zbikowski Gary Kimura.
CSE 451: Operating Systems Spring 2012 Module 7 Synchronization Ed Lazowska Allen Center 570.
Synchronization. Shared Memory Thread Synchronization Threads cooperate in multithreaded environments – User threads and kernel threads – Share resources.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts Amherst Operating Systems CMPSCI 377 Lecture.
5.6 Semaphores Semaphores –Software construct that can be used to enforce mutual exclusion –Contains a protected variable Can be accessed only via wait.
Synchronization (other solutions …). Announcements Assignment 2 is graded Project 1 is due today.
Race Conditions CS550 Operating Systems. Review So far, we have discussed Processes and Threads and talked about multithreading and MPI processes by example.
Synchronization CSCI 444/544 Operating Systems Fall 2008.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
OSE 2013 – synchronization (lec3) 1 Operating Systems Engineering Locking & Synchronization [chapter #4] By Dan Tsafrir,
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.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Mutual Exclusion.
Chapter 28 Locks Chien-Chung Shen CIS, UD
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
CHARLES UNIVERSITY IN PRAGUE faculty of mathematics and physics Advanced.NET Programming I 5 th Lecture Pavel Ježek
CS 3204 Operating Systems Godmar Back Lecture 7. 12/12/2015CS 3204 Fall Announcements Project 1 due on Sep 29, 11:59pm Reading: –Read carefully.
Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly execution.
Operating Systems CSE 411 CPU Management Dec Lecture Instructor: Bhuvan Urgaonkar.
A Methodology for Implementing Highly Concurrent Data Objects by Maurice Herlihy Slides by Vincent Rayappa.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
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.
CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Synchronization.
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.
December 1, 2006©2006 Craig Zilles1 Threads & Atomic Operations in Hardware  Previously, we introduced multi-core parallelism & cache coherence —Today.
Symmetric Multiprocessors: Synchronization and Sequential Consistency
Outline CPU caches Cache coherence Placement of data
CSE 120 Principles of Operating
CS703 – Advanced Operating Systems
Background on the need for Synchronization
Synchronization.
ICS143A: Principles of Operating Systems Final recap, sample questions
Atomic Operations in Hardware
Atomic Operations in Hardware
Chapter 5: Process Synchronization
Anton Burtsev November, 2017
Lecture 12: Peterson’s Solution and Hardware Support
COP 4600 Operating Systems Spring 2011
Practical Session 5 Synchronization
Concurrency: Locks Questions answered in this lecture:
COT 5611 Operating Systems Design Principles Spring 2014
COP 4600 Operating Systems Fall 2010
Thread Implementation Issues
COT 5611 Operating Systems Design Principles Spring 2012
Mutual Exclusion.
UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department
Lecture 2 Part 2 Process Synchronization
Coordination Lecture 5.
Implementing Mutual Exclusion
Implementing Mutual Exclusion
CSE 451: Operating Systems Winter 2007 Module 6 Synchronization
Kernel Synchronization II
Lecture 12: Peterson’s Solution and Hardware Support
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 451: Operating Systems Spring 2008 Module 7 Synchronization
CSE 451: Operating Systems Winter 2007 Module 6 Synchronization
CSE 451: Operating Systems Autumn 2009 Module 7 Synchronization
CSE 451: Operating Systems Spring 2007 Module 7 Synchronization
CSE 542: Operating Systems
Presentation transcript:

ICS143A: Principles of Operating Systems Lecture 15: Locking Anton Burtsev November, 2017

Race conditions Disk driver maintains a list of outstanding requests Each process can add requests to the list

List implementation no locks 1 struct list { 2 int data; 3 struct list *next; 4 }; ... 6 struct list *list = 0; 9 insert(int data) 10 { 11 struct list *l; 12 13 l = malloc(sizeof *l); 14 l->data = data; 15 l->next = list; 16 list = l; 17 }

Request queue (e.g. incoming network packets) Linked list, list is pointer to the first element

CPU1 allocates new request

CPU2 allocates new request

CPUs 1 and 2 update next pointer

CPU1 updates head pointer

CPU2 updates head pointer

State after the race

Mutual exclusion Only one CPU can update list at a time

List implementation with locks 1 struct list { 2 int data; 3 struct list *next; 4 }; 6 struct list *list = 0; struct lock listlock; 9 insert(int data) 10 { 11 struct list *l; 13 l = malloc(sizeof *l); acquire(&listlock); 14 l->data = data; 15 l->next = list; 16 list = l; release(&listlock); 17 } Critical section

How can we implement acquire()?

Spinlock 21 void 22 acquire(struct spinlock *lk) 23 { 24 for(;;) { 25 if(!lk->locked) { 26 lk->locked = 1; 27 break; 28 } 29 } 30 } Spin until lock is 0 Set it to 1

Still incorrect 21 void 22 acquire(struct spinlock *lk) 23 { 24 for(;;) { 25 if(!lk->locked) { 26 lk->locked = 1; 27 break; 28 } 29 } 30 } Two CPUs can reach line #25 at the same time See not locked, and Acquire the lock Lines #25 and #26 need to be atomic I.e. indivisible

Compare and swap: xchg Swap a word in memory with a new value Return old value

Correct implementation 1573 void 1574 acquire(struct spinlock *lk) 1575 { ... 1580 // The xchg is atomic. 1581 while(xchg(&lk−>locked, 1) != 0) 1582 ; 1592 }

xchgl instruction 0568 static inline uint 0569 xchg(volatile uint *addr, uint newval) 0570 { 0571 uint result; 0572 0573 // The + in "+m" denotes a read−modify−write operand. 0574 asm volatile("lock; xchgl %0, %1" : 0575 "+m" (*addr), "=a" (result) : 0576 "1" (newval) : 0577 "cc"); 0578 return result; 0579 }

Correct implementation 1573 void 1574 acquire(struct spinlock *lk) 1575 { ... 1580 // The xchg is atomic. 1581 while(xchg(&lk−>locked, 1) != 0) 1582 ; 1584 // Tell the C compiler and the processor to not move loads or stores 1585 // past this point, to ensure that the critical section’s memory 1586 // references happen after the lock is acquired. 1587 __sync_synchronize(); 1592 }

Deadlocks

Deadlocks

Lock ordering Locks need to be acquired in the same order

Locks and interrupts

Locks and interrupts Never hold a lock with interrupts enabled

Disabling interrupts 1573 void 1574 acquire(struct spinlock *lk) 1575 { 1576 pushcli(); // disable interrupts to avoid deadlock. 1577 if(holding(lk)) 1578 panic("acquire"); 1580 // The xchg is atomic. 1581 while(xchg(&lk−>locked, 1) != 0) 1582 ; ... 1587 __sync_synchronize(); 1592 } Disabling interrupts

Simple disable/enable is not enough If two locks are acquired Interrupts should be re-enabled only after the second lock is released Pushcli() uses a counter

Pushcli()/popcli() 1655 pushcli(void) 1656 { 1657 int eflags; 1658 1659 eflags = readeflags(); 1660 cli(); 1661 if(cpu−>ncli == 0) 1662 cpu−>intena = eflags & FL_IF; 1663 cpu−>ncli += 1; 1664 } ... 1667 popcli(void) 1668 { 1669 if(readeflags()&FL_IF) 1670 panic("popcli − interruptible"); 1671 if(−−cpu−>ncli < 0) 1672 panic("popcli"); 1673 if(cpu−>ncli == 0 && cpu−>intena) 1674 sti(); 1675 } Pushcli()/popcli()

Thank you!