Nested Mutex Design Document and Proposed Solution.

Slides:



Advertisements
Similar presentations
Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
Advertisements

Ken Birman 1. Refresher: Dekers Algorithm Assumes two threads, numbered 0 and 1 CSEnter(int i) { int J = i^1; inside[i] = true; turn = J; while(inside[J]
Deadlock and Starvation
Concurrency: Deadlock and Starvation Chapter 6. Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate.
Resource Access Protocols
Concurrency Control Part 2 R&G - Chapter 17 The sequel was far better than the original! -- Nobody.
Section 3. True/False Changing the order of semaphores’ operations in a program does not matter. False.
Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
1 Operating Systems, 122 Practical Session 5, Synchronization 1.
Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t.
3.1.3 Program Flow control_1 Understand the need for structure Breaking things down.
CY2003 Computer Systems Lecture 05 Semaphores - Theory.
CSC 322 Operating Systems Concepts Lecture - 29: by
Shared Counters and Parallelism Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Language Support for Lightweight transactions Tim Harris & Keir Fraser Presented by Narayanan Sundaram 04/28/2008.
CS533 - Concepts of Operating Systems 1 Class Discussion.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
UCDavis, ecs251 Fall /23/2007ecs251, fall Operating System Models ecs251 Fall 2007 : Operating System Models #3: Priority Inversion Dr. S.
Slide - 1 Dr Terry Hinton 6/9/05UniS - Based on Slides by Micro Analysis & Design An example of a Simulation Simulation of a bank: Three tasks or processes:
In.  This presentation will only make sense if you view it in presentation mode (hit F5). If you don’t do that there will be multiple slides that are.
Parallel Programming Philippas Tsigas Chalmers University of Technology Computer Science and Engineering Department © Philippas Tsigas.
(a) Alice and Bob are back together. Today Alice wants to send Bob a message that is secret and also authenticated, so that Bob "knows" the message came.
A Two-Lock Concurrent Queue Algorithm Maged M. Michael, Michael L. Scott University of Rochester Presented by Hussain Tinwala.
© 2004, D. J. Foreman 1 High Level Synchronization and Inter-Process Communication.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Maged M.Michael Michael L.Scott Department of Computer Science Univeristy of Rochester Presented by: Jun Miao.
11/18/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
11/21/20151 Operating Systems Design (CS 423) Elsa L Gunter 2112 SC, UIUC Based on slides by Roy Campbell, Sam.
Deadlock Detection and Recovery
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
A Methodology for Creating Fast Wait-Free Data Structures Alex Koganand Erez Petrank Computer Science Technion, Israel.
1 CMSC421: Principles of Operating Systems Nilanjan Banerjee Principles of Operating Systems Acknowledgments: Some of the slides are adapted from Prof.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Monitors and Blocking Synchronization Dalia Cohn Alperovich Based on “The Art of Multiprocessor Programming” by Herlihy & Shavit, chapter 8.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
Introduction to Embedded Systems Rabie A. Ramadan 5.
CS533 – Spring Jeanie M. Schwenk Experiences and Processes and Monitors with Mesa What is Mesa? “Mesa is a strongly typed, block structured programming.
Practice Chapter Five.
6.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Module 6: Process Synchronization.
Implementing Lock. From the Previous Lecture  The “too much milk” example shows that writing concurrent programs directly with load and store instructions.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 6: Process Synchronization.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
© 2004, D. J. Foreman 1 Monitors and Inter-Process Communication.
3/17/2016cse synchronization-p2 © Perkins, DW Johnson and University of Washington1 Synchronization Part 2 CSE 410, Spring 2008 Computer.
Homework-6 Questions : 2,10,15,22.
Where Testing Fails …. Problem Areas Stack Overflow Race Conditions Deadlock Timing Reentrancy.
Control Structures WHILE Statement Looping. S E Q C E N U E REPITITION …a step or sequence of steps that are repeated until some condition is satisfied.
Tutorial 3: Homework 2 and Project 2
Implementing Mutual Exclusion Andy Wang Operating Systems COP 4610 / CGS 5765.
Lecture 5 Page 1 CS 111 Summer 2013 Bounded Buffers A higher level abstraction than shared domains or simple messages But not quite as high level as RPC.
Pitfalls: Time Dependent Behaviors CS433 Spring 2001 Laxmikant Kale.
CS140 Project Session Notes #1: Threads Haobo Xu, TA Fall Based on Ben Sapp’s slides Download these slides from
EMERALDS Landon Cox March 22, 2017.
Auburn University COMP 3500 Introduction to Operating Systems Synchronization: Part 4 Classical Synchronization Problems.
Background on the need for Synchronization
Multiple Writers and Races
Chapter 5: Process Synchronization
Lecture 13: Producer-Consumer and Semaphores
MODERN OPERATING SYSTEMS Third Edition ANDREW S
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 2 Part 2 Process Synchronization
Implementing Mutual Exclusion
Implementing Mutual Exclusion
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 13: Producer-Consumer and Semaphores
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Presentation transcript:

Nested Mutex Design Document and Proposed Solution

Important TCB DS Priority_Control Current_Priority; Priority_Control Real_Priority; Int32_t resource_count; #if Strict order Chain_Control lock_mutex

Mutex Control Block related DS Core_Mutex_Attributes: - Priority_Inheritance - Priority_ceiling Core_Mutex_Order_List: - Chain_Node lock_queue; - Priority_Control priority_before; Core_Mutex_Control: - Core_Mutex_Attribute Attr.. - Thread_Queue_Control wait_queue; - nest_count - Thread_Control *holder #if strict order - Core_Mutex_Order_list queue

Relation Between Thread and Mutex Chain_Control lock_mutex(in TCB) - Chain_Node Node - Chain_Node *fill Core_Mutex_Order_list queue(in MCB) - Chain_Node lock_queue; - Priority_Control priority_before; Chain Structure to manage nested mutex and priority inheritance cases: Lock_mutex (holder thread) NodeFillqueue (m1)Lock_queueP_before PrevNext queue(m2) Lock_queueP_before queue(m3) Lock_queueP_before PrevNextPrevNext

Mutex Locking Mechanism _API_Mutex_Lock() (apimutexlock.c) _Core_Mutex_Seize() (coremuteximpl.h) _Core_Mutex_Seize_Body() (coremuteximpl.h) trylock_body()

Mutex_Attributes Mutex_State Thread tries to acquire mutex MutexAvailableFIFO - Set holder - inc rsc_count - nest_cnt:=1 (Successfully Acquired the lock) Strict_Order - Set holder - inc rsc_count - nest_cnt:=1 Prepend Mutex’s DS in Chain Structure, set priority_before, Successfully acquired mutex Ceiling Does not care much of it now. Not AvailableRe-entrantNesting Behavior - Allowed - NA - POSIX - Blocks

Implementation and Test Cases M1M2M3M4M5M6M7M8M9M W Mutex Acquired Priority_before Chain Structure for strict order mutex Thread T1 is the holder thread for all mutexes having real and current priority = 8 has acquired above mutexes and now is waiting on mutex M10

Thread T2 of priority=1(highest) tries to acquire mutex m5 which is already acquired by the thread 1 - Following action takes place: - Current Priority of T1 escalates to 1. - re-enqueued T1 with updated priority. State: T1.Current_priority = 1 (This is the current implementation of rtems which leads to nested mutex problem in priority inheritance problem. Problem occurs because instead of checking priority_before of thread T1 while it acquired mutex m5 we check the current priority of thread T1) Now in next slide I explain my solution----  M1M2M3M4M5M6M7M8M9M W

Solution Algorithm We should check the recorded priority_before of mutex m5 while it was acquired by thread T1 rather than checking its current_priority. This will help us in proper step down of priorities. Mx.priority_before < T2.current_priority Escalate priority_before for all mutex acquired after M5 which satisfies above condition. This ensures proper step down while releasing mutexes. Do Nothing. Current code properly enqueues T2 according to its priority in wait queue M1M2M3M4M5M6M7M8M9M W Updated Chain Structure True False

A new thread T3 of priority=4 tries to acquire mutex m3 which is again already acquired thread T1. So according to algorithm the state will become: Now a new thread T4 of priority = 3tries to acquire mutex M5. So according to algorithm all mutex ahead of M5 will be tested. As M6.priority_before < T4.current_priority evaluates false, therefore no change happen to chain structure. It will be inserted to wait_queue of M5 according to its priority. No Change M1M2M3M4M5M6M7M8M9M W M1M2M3M4M5M6M7M8M9M W

Now a new thread T5 of priority = 3 tries to acquire mutex M4. So according to algorithm all mutex ahead of M5 will be tested As M5.priority_before < T4.current_priority evaluates True we iterative update the chain structure. I guess I have covered all the test scenarios from my end. Please let me know if you come up with any other test-cases which fails the solution. Algorithm Analysis: Cost of Updation: O(n) n -> Number of mutex acquired by the holder thread. Should not be the problem as thread won’t acquire so many mutex. Algorithm should work smoothly and efficiently. Also let me know when the efficiency will break in multi-processor case. I don’t feel there should be any problem for that with this solution. M1M2M3M4M5M6M7M8M9M W