Chapter 7 - Resource Access Protocols (Critical Sections) Protocols: No Preemptions During Critical Sections Once a job enters a critical section, it cannot.

Slides:



Advertisements
Similar presentations
Chapter 6 Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles, 6/E William Stallings Patricia Roy Manatee Community.
Advertisements

Washington WASHINGTON UNIVERSITY IN ST LOUIS Real-Time: Periodic Tasks Fred Kuhns Applied Research Laboratory Computer Science Washington University.
Real Time Scheduling.
Priority Inheritance and Priority Ceiling Protocols
Washington WASHINGTON UNIVERSITY IN ST LOUIS Resource and Resource Access Control Fred Kuhns Applied Research Laboratory Computer Science and Engineering.
Outline Introduction Assumptions and notations
Introduction to Embedded Systems Resource Management - III Lecture 19.
Priority INHERITANCE PROTOCOLS
Copyright © 2000, Daniel W. Lewis. All Rights Reserved. CHAPTER 8 SCHEDULING.
1 EE5900 Advanced Embedded System For Smart Infrastructure RMS and EDF Scheduling.
ICS Principles of Operating Systems Lectures 8 and 9 - Deadlocks Prof. Dmitri V. Kalashnikov dvk ics.uci.edu Slides © Prof. Nalini Venkatasubramanian.
0 Synchronization Problem Resource sharing –Requires mutual exclusion –Critical section A code section that should be executed mutually exclusively by.
CS5270 Lecture 31 Uppaal, and Scheduling, and Resource Access Protocols CS 5270 Lecture 3.
Resource Access Protocols
CprE 458/558: Real-Time Systems (G. Manimaran)1 CprE 458/558: Real-Time Systems Resource Access Control Protocols.
CSE 522 Real-Time Scheduling (3)
Chapter 6 Concurrency: Deadlock and Starvation
Tanenbaum Ch 6 Silberschatz Ch 7
Chapter 6 Dynamic Priority Servers
Chapter 7: Deadlocks. 7.2 Chapter Objectives To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks.
Resource Access Control in Real-Time Systems Resources, Resource Access, and How Things Can Go Wrong: The Mars Pathfinder Incident Resources, Critical.
The ‘deadlock’ conditions Reviewing some key points concerning the potential for ‘deadlock’ in an operating system.
© Andy Wellings, 2004 Roadmap  Introduction  Concurrent Programming  Communication and Synchronization  Completing the Java Model  Overview of the.
Witawas Srisa-an Chapter 6
CPSC 4650 Operating Systems Chapter 6 Deadlock and Starvation
Resource Access Control (Part I) The Mars Pathfinder Incident Resource Model Priority Inversion.
1 Concurrency: Deadlock and Starvation Chapter 6.
Spring 2002Real-Time Systems (Shin) Rate Monotonic Analysis Assumptions – A1. No nonpreemptible parts in a task, and negligible preemption cost –
UCDavis, ecs251 Fall /23/2007ecs251, fall Operating System Models ecs251 Fall 2007 : Operating System Models #3: Priority Inversion Dr. S.
Chapter 4 – Periodic Task Scheduling In many real-time systems periodic tasks dominate the demand. Three classic periodic task scheduling algorithms: –
Introduction to Embedded Systems
Introduction to Embedded Systems Rabie A. Ramadan 6.
Real-Time Scheduling CS4730 Fall 2010 Dr. José M. Garrido Department of Computer Science and Information Systems Kennesaw State University.
Real Time Scheduling Telvis Calhoun CSc Outline Introduction Real-Time Scheduling Overview Tasks, Jobs and Schedules Rate/Deadline Monotonic Deferrable.
Real-Time Scheduling CS4730 Fall 2010 Dr. José M. Garrido Department of Computer Science and Information Systems Kennesaw State University.
Deadlocks Silberschatz Ch. 7 and Priority Inversion Problems.
- 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2006 Universität Dortmund Periodic scheduling For periodic scheduling, the best that we can do is to.
B. RAMAMURTHY 12/25/2015 Realtime System Fundamentals : Scheduling and Priority-based scheduling Pag e 1.
1 Real-Time Scheduling. 2Today Operating System task scheduling –Traditional (non-real-time) scheduling –Real-time scheduling.
CSCI1600: Embedded and Real Time Software Lecture 24: Real Time Scheduling II Steven Reiss, Fall 2015.
Deadlock Operating Systems: Internals and Design Principles.
Introduction to Embedded Systems Rabie A. Ramadan 5.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
CS333 Intro to Operating Systems Jonathan Walpole.
Sandtids systemer 2.modul el. Henriks 1. forsøg m. Power Point.
Chapter 8 Deadlocks. Objective System Model Deadlock Characterization Methods for Handling Deadlocks Deadlock Prevention Deadlock Avoidance Deadlock Detection.
Undergraduate course on Real-time Systems Linköping University TDDD07 Real-time Systems Lecture 2: Scheduling II Simin Nadjm-Tehrani Real-time Systems.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 6 Deadlocks Slide 1 Chapter 6 Deadlocks.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Distributed Process Scheduling- Real Time Scheduling Csc8320(Fall 2013)
Informationsteknologi Monday, October 1, 2007Computer Systems/Operating Systems - Class 111 Today’s class Deadlock.
REAL-TIME OPERATING SYSTEMS
EEE Embedded Systems Design Process in Operating Systems 서강대학교 전자공학과
Scheduling and Resource Access Protocols: Basic Aspects
EEE 6494 Embedded Systems Design
Lecture 24: Process Scheduling Examples and for Real-time Systems
Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy cse321-fall2014 9/20/2018.
Chapter 7 Deadlock.
Rate Monotonic Analysis For Real-Time Scheduling A presentation for
Realtime Scheduling Algorithms
Realtime System Fundamentals : Scheduling and Priority-based scheduling B. Ramamurthy cse321-fall /27/2018.
Chapter 7: Deadlocks.
CSCI1600: Embedded and Real Time Software
CSCI1600: Embedded and Real Time Software
Processes and operating systems
Deadlocks Session - 13.
Operating System , Fall 2000 EA101 W 9:00-10:00 F 9:00-11:00
CHAPTER 8 Resources and Resource Access Control
Real-Time Process Scheduling Concepts, Design and Implementations
Real-Time Process Scheduling Concepts, Design and Implementations
Presentation transcript:

Chapter 7 - Resource Access Protocols (Critical Sections) Protocols: No Preemptions During Critical Sections Once a job enters a critical section, it cannot be preempted until it finishes the critical section Priority Inheritance Protocol (for static scheduled systems) A job that is blocking a high priority job that seek the critical section, has its priority elevated to cause it to finish using the critical section Priority Ceiling Protocol (for static scheduled system) Jobs are not allowed to enter a critical section if there are jobs that can block it. Stack Resource Policy (for static or dynamic scheduled systems) A job that needs a resource that is not available, is blocked at the time it attempts to preempt, instead of at the later time when it would request the resource

Definitions Resource Types – private, shared, mutually exclusive Critical Sections – code executed under mutual exclusion: At most one task can be holding the resource at a given time. All other tasks ready to use the resources are blocked Semaphores - Resource R k Semaphore S k A critical section operating on R k Begins with a wait(S k ) End with a signal(S k )

Critical Sections

Implications Implications of Critical Sections: Protocols must include max delays due to potential blocking in worst-case computation times when scheduling. Leads to necessity for very conservative scheduling to guarantee not missing deadlines.

Blocking

Chained Blocking

Priority Inversion

Deadlock

Denying Preemptions during Critical Sections Denying preemption during execution of a critical section eliminates priority inversion. Leads to unnecessary blocking (delay) of higher priority tasks.

Priority Inheritance Protocol (applicable for fixed priority scheduling – think Rate Monotonic)

Priority Inheritance Protocol

Some Properties:

Priority Ceiling Protocol (applicable for fixed priority scheduling – again think Rate Monotonic)

Priority Ceiling Protocol

Some Properties:

Stack Resource Policy (applicable for fixed or dynamic scheduling – think Rate Monotonic or Earliest Deadline First) Each task has: A priority p i (assigned either statically or dynamically), p a > p b means execution of a is more important than b A preemption level i (assigned statically) a > b D a < D b (relative deadlines) J a can preempt J b ONLY IF a > b Preemption levels are static and are used to predict potential blocking in

Stack Resource Policy Definitions (Current Ceilings): Current Resource Ceiling (computed as a function of the units of R that are available): Denotes the number of units of R that are currently available Denotes the maximum requirement of job J for R System Ceiling (the maximum of the current ceilings of all of the resources): s max{C R1 : I= 1,2,…,m) i.e., the highest preemption level of those jobs that could be blocked on R i.e., the maximum of the Current Resource Ceilings

Stack Resource Policy Protocol: A job is not allowed to preempt until: its priority is the highest among those jobs ready to run, and its preemption level is higher than the system ceiling

Stack Resource Policy

Stack Resource Policy Example Given: (J 1 J 2 J 3 ) that share (R 1 R 2 R 3 ) where: R 1 consists of 3 units, R 2 of 1, R 3 of 3, and C R1 (3) = max 0 = 0 C R1 (2) = max { (J 3 ) } = max {1} = 1 C R1 (1) = max { (J 2 ), (J 3 ) } = max { 2, 1} = 2 C R1 (0) = max { (J 1 ), (J 2 ), (J 3 ) } = max { 3, 2, 1} = 3 = units available,= maximum requirement for the job

Stack Resource Policy Example Protocol: A job is not allowed to preempt until: its priority is the highest among those jobs ready to run, its preemption level is higher than the system ceiling t 0 : J 3 begins executing and the system ceiling = 0 because all resources are completely available. When J 3 enters its first critical section, it takes the unit of R 2. The ceiling is set to the highest preemption level among the tasks that could be blocked on R 2 ; that is s = 2 = 2. As a consequence, J 2 is blocked by the preemption test and J 3 continues to execute. t 1 : When J 3 enters its nested critical section, taking all units of R 1, the system ceiling is raised to s = 1 = 3. This causes J 1 to be blocked by the preemption test. t 2 : As J 3 releases R 1, the system ceiling becomes s = 2 = 2 (the highest preemption level among tasks that could be blocked on R 2 ; thus J 1 preempts J 3 and starts executing. Once J 1 is started, it is never blocked during its execution because the condition 1 < s guarantees that all the resources needed by J 1 are available. As J 1 terminates, J 3 resumes execution and releases resource R 2. t 3 : As R 2 is released, the system ceiling returns to zero and J 2 can preempt J 3. Again, once J 2 is started, all the resources it needs are available; thus J 2 is never blocked.

Stack Resource Policy Properties:

The End