ES Dr. Khurram Lecture-4-A

Embedded Systems
Program: BS (Electrical Engineering)

Semester: Fall 2017
Lecture 04
Instructor: Dr. Khurram Bhatti
Assistant Professor
khurram.bhatti@itu.edu.pk
Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore www.itu.edu.pk
Real-time Embedded Systems
RESOURCE ACCESS PROTOCOLS
2 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore
1
Resource
o A resource is any software structure or hardware that can be used
by a process (task) to advance its execution
o Typical Resource: A data structure, A set of variables, A main
memory area, A file, A set of registers of a peripheral device
o Private Resource: Dedicated to a particular process (task)
o Shared Resource: More than one tasks can use
o Exclusive Resource: A shared resource protected against

concurrent accesses

Resource
o Exclusive Resource Often the case in sequential data
processing systems
o Any concurrent operating system should use appropriate
resource access protocols to guarantee a mutual exclusion
among competing tasks.
o A piece of code executed under mutual exclusion constraints

is called a critical section.
2
Resource
Critical Sections
Any task that needs to enter a critical section must wait until no
other task is holding the resource Mutual Exclusion!
When a task leaves a critical section, the resource associated

with the critical section becomes free
A task waiting for an exclusive resource is said to be blocked on

that resource
Free resource can be allocated to another waiting task, if any.


Resource
Critical Sections
Operating systems typically provide a general synchronization
tool, called a semaphore that can be used by tasks to build
critical sections
A semaphore is a kernel data structure
Semaphore can be accessed only through two kernel primitives:
wait (or Request for Semaphore S)
signal (or Release of Semaphore S)
Each exclusive resource Rk must be protected by a different
semaphore Sk
Each critical section operating on a resource Rk must begin with
a wait(Sk) primitive and end with a signal(Sk) primitive.
3
Resource Access Protocols
o When concurrent tasks use shared resources in
exclusive mode, blocking issues appear!
o Such protocols are designed
o To avoid blocking
o Bound the maximum blocking time of each task.
o Blocking times can be used in the schedulability

analysis to extend the guarantee tests derived for
periodic task sets.

Priority Inversion Phenomenon
Priority inversion occurs due to blocking on shared
resources in mutual exclusion mode
Example: T1 & T2 share an exclusive resource Rk (such as a

list) on which two operations (such as insert and remove) are
defined
To guarantee the mutual exclusion, both operations must be

defined as critical sections
A semaphore Sk is being used for mutual exclusion
4
Priority Inversion: Example
Critical Critical
Section Section

5
The maximum blocking time that T1 may experience is equal to
the time needed by T2 to execute its critical section
This is called Direct Blocking
Consequence of the mutual exclusion
Necessary to protect the shared resource against concurrent

accesses of competing tasks.

Unfortunately, the blocking time of a task on a busy resource

cannot be bounded by the duration of the critical section
executed by the lower-priority task
Lets reconsider the same example with an intermediate priority

task
6

A priority inversion is said to occur in the interval [t3, t6]
The highest-priority task T1 waits for the execution of lower-

priority tasks (T2 and T3).
The duration of priority inversion is unbounded.
Since any intermediate-priority task that can preempt T3 will

indirectly block T1
7
(Un-controlled) Priority Inversion is a Problem!!
Resource Access Protocols have been defined to avoid priority

inversion
They (often) raise the priority of a task when accessing a

shared resource for entering and exiting critical sections

Notations
Following notations are used in examples
E means executing 1 unit of time

S means executing 1 unit of time while accessing semaphore S
+S means Requesting semaphore S
S- means Releasing semaphore S
8
Non-Preemptive Protocol (NPP)
A simple solution that avoids the unbounded priority inversion

problem
Disallows preemption during the execution of any critical
section
Can be implemented by raising the priority of a task to the
highest priority level whenever it enters a shared resource
The dynamic priority is then reset to the nominal when the task
exits the critical section

Any problem with this?
9
Any problem with this?
Only appropriate when tasks use short critical sections!

Blocking Time Calculation:
Since a task inside a resource R cannot be preempted, only
one resource can be locked at any time
Hence, a task can be blocked at most for the length of a single

critical section belonging to lower priority tasks
The maximum blocking time a task can suffer is given by the

duration of the longest critical section among those belonging
to lower priority tasks
10
Pros:
No preemption => No intermediate priority tasks can
run
Useful for short critical sections
Cons :
All tasks are waiting (even those who are not
sharing the protected resource)

Multiple Resource Sharing
Tasks share several resources controlled by several semaphores
Possible deadlocks!
Simple inheritance (of higher priority level) is not able to solve the
deadlock situation
Simple solution : enforce the order of locks to be the same in every

task.
But it is not always possible to write applications this way.

11
Multiple Resource Sharing Deadlock situation

Priority Ceiling
Basic Idea: Handle the critical sections at runtime rather than
deciding offline
A Priority Ceiling is associated with each resource (just like

priority associated with a task)
Definition of priority ceiling of a semaphore : Maximum priority

of tasks that may lock the semaphore
This value is determined offline!
12
Priority Ceiling based protocols
1. Highest Lock/Immediate Ceiling Priority Protocol

(ICPP)
2. Priority Ceiling Protocol (PCP)

Highest Lock/Immediate Ceiling Priority Protocol (ICPP)
Each semaphore S has an offline value of priority ceiling

The task which locked successfully semaphore S inherits a priority
immediately greater than Priority Ceiling of S
As a consequence, an other task potentially needing S cannot be run
Highest Lock of ICPP works as following:
Calculate Priority Ceiling of each resource, Save it!
At run time, when any task successfully locks on a resource, it
inherits (starts running at) the priority equal to the locked
resources priority ceiling + 1
Current Priority= Priority Ceiling of locked resource + 1
13
Highest Lock/Immediate Ceiling Priority Protocol
Priority with S Current Priority of Ti=3
Current Priority of Tj=4

Highest Lock/Immediate Ceiling Priority Protocol
(ICPP)
Improves NPP by raising the priority of a task that locks a
resource to the highest priority among the tasks sharing that
resource
As soon as a task locks a resource/semaphore, its dynamic
priority is raised to the ceiling of the resource
The dynamic priority is then reset to the nominal value when
the task exits the critical section
A task can only be blocked by critical sections belonging to
lower priority tasks with a resource ceiling higher than or
equal to the task s priority
14
Exercise: determine Ceilings and draw schedule with
Highest Lock priorities
Task Priority Execution Sequence Release time

A 4 (High) E E +S2 S2 +S3 S2- S3- E E 5
Ceiling(S1)=? Ceiling(S2)=? Ceiling(S3)=?
B 1 (Low) E +S1 S1 S1 S1 S1 +S2 S2 S1- S2- E E 1

Determine Ceilings and draw schedule with Highest
Lock/ICPP Protocol.
Task Priority Execution Sequence Release

level time
T1 4 E +S2 S2 +S3 S2- S3- E E 5
Ceiling(S1)=? Ceiling(S2)=? Ceiling(S3)=?
T2 2 E +S1 S1 S1 +S2 S2 S2 S1- S2- E E 2

T3 1 E E E +S1 S1 S1 S1 S1 +S2 S2 S1- S2- E E 0
15
Limitation
Priority is raised irrespective of the fact that

intermediate priority tasks may not use the same
resources

Priority Ceiling Protocol (PCP)
Basic Idea: To avoid multiple blocking, PCP rules do

not allow a task to enter a critical section if there are
locked semaphores that could block it
Once a task enters its first critical section, it can

never be blocked by lower-priority tasks until its
completion
16
Priority Ceiling Protocol (PCP) How?
For each resource/semaphore, a priority ceiling is defined, whose value

is equal to the highest priority of all the tasks that may lock it.
When a task Ti attempts to execute one of its critical sections, it will be

suspended unless Tis priority is higher than the priority ceiling of ALL
semaphores currently locked by tasks other than Ti
If task Ti is unable to enter its critical section for this reason, the task
that holds the lock on the semaphore with the highest priority ceiling is
said to be blocking Ti and hence inherits the priority of Ti.

Priority Ceiling Protocol (PCP) How?
As long as a task Ti is not attempting to enter one of its

critical sections (i.e., requesting for normal execution), it will
preempt every task that has a lower priority than Ti.
Under PCP a task Ti can be blocked from entering a critical

section if any other task is currently holding a semaphore
whose priority ceiling is greater than or equal to the priority of
task Ti.
17
Priority Ceiling Protocol (PCP) Example
3 tasks in descending priority: T1 > T2 > T3

3 Semaphores: SA, SB, SC
Semaphore Priority Ceiling?
T1 accesses SA & SB C(SA) = Priority of T1
C(SB) = Priority of T1
T2 accesses SC C(SC) = Priority of T2
T3 accesses SB & SC

C(SA) = P1
C(SB) = P1
C(SC) = P2
+SA
+SA SA- +SB SB-
+Sc +SB SB- Sc-
Priority
evolution of
T3
18
At time t0, T3 is activated, and since it is the only task ready to run, it starts executing and later locks semaphore SC.
At time t1, T2 becomes ready and preempts T3.
At time t2, T2 attempts to lock SC, but it is blocked by the protocol because P2 is not greater than C(SC). Then, T3
inherits the priority of T2 and resumes its execution.
At time t3, T3 successfully enters its nested critical section by locking SB. Note that T3 is allowed to lock SB because no
semaphores are locked by other tasks
At time t4, while T3 is executing at a priority P3 = P2, T1 becomes ready and preempts T3 because P1 > P2 > P3.
At time t5, T1 attempts to lock SA, which is not locked by any task. However, T1 is blocked by the protocol because its
priority is not higher than C(SB), which is the highest ceiling among all semaphores currently locked by the other tasks.
Since SB is locked by T3, T3 inherits the priority of T1 and resumes its execution.
At time t6, T3 exits its nested critical section, unlocks SB, and, T3 returns to priority P3 = P2. since P1 > C(SC) and P1 >
P3, T1 preempts T3 and executes until completion.
At time t7, T1 is completed, and T3 resumes its execution at a priority P3 = P2.
At time t8, T3 exits its outer critical section, unlocks SC, and, since T2 is blocked, T3 returns to its nominal priority P3. At
this point, T2 preempts T3 and executes until completion.
At time t9, T2 is completed; thus, T3 resumes its execution.

Priority Ceiling Protocol (PCP) Blocking time Calculation
Exercise : Draw schedule under PCP
Task Priority Execution Sequence Release

time
T1 High: 3 E E E +S3 S3 +S2 S3- S2- E E E 6
T2 Medium: 2 E +S3 S3 S3 +S4 S4 S4- +S1 S1 S1 S1- S3- E E 3
T3 Low: 1 E E +S4 S4 S4 S4- +S2 S2 +S4 S2- S4 S4 S4- E E 0
19

ES Dr. Khurram Lecture-4-A

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ES Dr. Khurram Lecture-4-A

Uploaded by

Copyright:

Available Formats

Embedded Systems

Program: BS (Electrical Engineering)

Real-time Embedded Systems

RESOURCE ACCESS PROTOCOLS

2 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

o Private Resource: Dedicated to a particular process (task)

o Shared Resource: More than one tasks can use

o Exclusive Resource: A shared resource protected against

3 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

o A piece of code executed under mutual exclusion constraints

4 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

When a task leaves a critical section, the resource associated

A task waiting for an exclusive resource is said to be blocked on

Free resource can be allocated to another waiting task, if any.

Real-time Embedded Systems

o Blocking times can be used in the schedulability

7 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

Example: T1 & T2 share an exclusive resource Rk (such as a

To guarantee the mutual exclusion, both operations must be

8 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

9 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

10 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

This is called Direct Blocking

Consequence of the mutual exclusion

Necessary to protect the shared resource against concurrent

11 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

Unfortunately, the blocking time of a task on a busy resource

Lets reconsider the same example with an intermediate priority

12 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

13 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

The highest-priority task T1 waits for the execution of lower-

The duration of priority inversion is unbounded.

Since any intermediate-priority task that can preempt T3 will

14 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Resource Access Protocols have been defined to avoid priority

They (often) raise the priority of a task when accessing a

15 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

E means executing 1 unit of time

16 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

A simple solution that avoids the unbounded priority inversion

17 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

Any problem with this?

18 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Any problem with this?

Only appropriate when tasks use short critical sections!

19 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

Hence, a task can be blocked at most for the length of a single

The maximum blocking time a task can suffer is given by the

Real-time Embedded Systems

Tasks share several resources controlled by several semaphores

Simple solution : enforce the order of locks to be the same in every

But it is not always possible to write applications this way.

23 Dr. M. Khurram Bhatti Embedded Systems, Fall 2017, ITU, Lahore

Real-time Embedded Systems

A Priority Ceiling is associated with each resource (just like

Definition of priority ceiling of a semaphore : Maximum priority