Embedded Systems

7. Shared Resources

© Lothar Thiele
Computer Engineering and Networks Laboratory
Where we are …

1. Introduction to Embedded Systems

2. Software Development
3. Hardware-Software Interface
4. Programming Paradigms
Software Hardware-
5. Embedded Operating Systems
Software
6. Real-time Scheduling
7. Shared Resources
8. Hardware Components
Hardware 9. Power and Energy
10. Architecture Synthesis

7-2
Ressource Sharing

7-3
Resource Sharing
 Examples of shared resources: data structures, variables, main memory area,
file, set of registers, I/O unit, … .
 Many shared resources do not allow simultaneous accesses but require mutual
exclusion. These resources are called exclusive resources. In this case, no two
threads are allowed to operate on the resource at the same time.

 There are several methods available to protect exclusive resources, for example
 disabling interrupts and preemption or
 using concepts like semaphores
and mutex that put threads into the
blocked state if necessary.

7-4
Protecting Exclusive Resources using Semaphores
 Each exclusive resource Ri
must be protected by a different
semaphore Si . Each critical
section operating on a resource
must begin with a wait(Si)
primitive and end with a
signal(Si) primitive.

 All tasks blocked on the same resource are kept in a queue associated with the
semaphore. When a running task executes a wait on a locked semaphore, it
enters a blocked state, until another tasks executes a signal primitive that
unlocks the semaphore.
7-5
Example FreeRTOS (ES-Lab)
To ensure data consistency is maintained at all times access to a resource that is
shared between tasks, or between tasks and interrupts, must be managed using a
‘mutual exclusion’ technique.

One possibility is to disable all interrupts:

...
taskENTER_CRITICAL();
... /* access to some exclusive resource */
taskEXIT_CRITICAL();
...

This kind of critical sections must be kept very short, otherwise they will adversely
affect interrupt response times.

7-6
Example FreeRTOS (ES-Lab)
Another possibility is to use mutual exclusion: In FreeRTOS, a mutex is a special type of
semaphore that is used to control access to a resource that is shared between two or
more tasks. A semaphore that is used for mutual exclusion must always be returned:

 When used in a mutual exclusion scenario, the mutex can be thought of as a

token that is associated with the resource being shared.

 For a task to access the resource legitimately, it must first successfully ‘take’
the token (be the token holder). When the token holder has finished with the
resource, it must ‘give’ the token back.

 Only when the token has been returned can another task successfully take the
token, and then safely access the same shared resource.

7-7
Example FreeRTOS (ES-Lab)

7-8
 Example FreeRTOS (ES-Lab)
some defined constant for infinite timeout;
otherwise, the function would return if the
Example: create mutex semaphore mutex was not available for the specified time

SemaphoreHandle_t xMutex; void vTask1( void *pvParameters ) {

for( ;; ) {
int main( void ) { ...
xMutex = xSemaphoreCreateMutex(); xSemaphoreTake(xMutex,portMAX_DELAY);
if( xMutex != NULL ) { ... /* access to exclusive resource */
xTaskCreate(vTask1,“Task1",1000,NULL,1,NULL); xSemaphoreGive(xMutex);
xTaskCreate(vTask2,“Task2",1000,NULL,2,NULL); ... }
vTaskStartScheduler(); }
}
for( ;; ); void vTask2( void *pvParameters ) {
} for( ;; ) {
...
xSemaphoreTake(xMutex,portMAX_DELAY);
... /* access to exclusive resource */
xSemaphoreGive(xMutex);
... }
}
7-9
Ressource Sharing
Priority Inversion

7 - 10
Priority Inversion (1)
Unavoidable blocking:

7 - 11
Priority Inversion (2)
Priority Inversion:

can last arbitrarily long

[But97, S.184]

7 - 12
Solutions to Priority Inversion
Disallow preemption during the execution of all critical sections. Simple approach,
but it creates unnecessary blocking as unrelated tasks may be blocked.

7 - 13
Resource Access Protocols
Basic idea: Modify the priority of those tasks that cause blocking. When a task Ji
blocks one or more higher priority tasks, it temporarily assumes a higher priority.

Specific Methods:
 Priority Inheritance Protocol (PIP), for static priorities
 Priority Ceiling Protocol (PCP), for static priorities
 Stack Resource Policy (SRP),
for static and dynamic priorities
 others …

7 - 14
Priority Inheritance Protocol (PIP)
Assumptions:
n tasks which cooperate through m shared resources; fixed priorities, all
critical sections on a resource begin with a wait(Si) and end with a
signal(Si) operation.

Basic idea:
When a task Ji blocks one or more higher priority tasks, it temporarily assumes
(inherits) the highest priority of the blocked tasks.

Terms:
We distinguish a fixed nominal priority Pi and an active priority pi larger or
equal to Pi. Jobs J1, …Jn are ordered with respect to nominal priority where J1
has highest priority. Jobs do not suspend themselves.
7 - 15
Priority Inheritance Protocol (PIP)
Algorithm:
 Jobs are scheduled based on their active priorities. Jobs with the same priority are
executed in a FCFS discipline.
 When a job Ji tries to enter a critical section and the resource is blocked by a lower
priority job, the job Ji is blocked. Otherwise it enters the critical section.
 When a job Ji is blocked, it transmits its active priority to the job Jk that holds the
semaphore. Jk resumes and executes the rest of its critical section with a priority
pk=pi (it inherits the priority of the highest priority of the jobs blocked by it).
 When Jk exits a critical section, it unlocks the semaphore and the highest priority
job blocked on that semaphore is awakened. If no other jobs are blocked by Jk,
then pk is set to Pk, otherwise it is set to the highest priority of the jobs blocked by
Jk.
 Priority inheritance is transitive, i.e. if 1 is blocked by 2 and 2 is blocked by 3, then
3 inherits the priority of 1 via 2.

7 - 16
Priority Inheritance Protocol (PIP)
Example:

Direct Blocking: higher-priority job tries to acquire a resource held by a lower-priority job
Push-through Blocking: medium-priority job is blocked by a lower-priority job that has
.

inherited a higher priority from a job it directly blocks

7 - 17
Priority Inheritance Protocol (PIP)
Example with nested critical sections:
priority does not change

a a a

[But97, S. 189]

7 - 18
Priority Inheritance Protocol (PIP)
Example of transitive priority inheritance:
J1 blocked by J2, J2 blocked by J3.
J3 inherits priority from J1 via J2.

[But97, S. 190]

7 - 19
Priority Inheritance Protocol (PIP)
Still a Problem: Deadlock
…. but there are other protocols like the Priority Ceiling Protocol …

[But97, S. 200]

7 - 20
The MARS Pathfinder Problem (1)
“But a few days into the mission, not long after Pathfinder started gathering
meteorological data, the spacecraft began experiencing total system resets, each
resulting in losses of data.

7 - 21
The MARS Pathfinder Problem (2)
“VxWorks provides preemptive priority scheduling of threads. Tasks on the
Pathfinder spacecraft were executed as threads with priorities that were assigned
in the usual manner reflecting the relative urgency of these tasks.”

“Pathfinder contained an "information bus", which you can think of as a shared

memory area used for passing information between different components of the
spacecraft.”

 A bus management task ran frequently with high priority to move certain kinds of
data in and out of the information bus. Access to the bus was synchronized with
mutual exclusion locks (mutexes).”

7 - 22
The MARS Pathfinder Problem (3)
 The meteorological data gathering task ran as an infrequent, low priority thread.
When publishing its data, it would acquire a mutex, do writes to the bus, and release
the mutex.
 The spacecraft also contained a communications task that ran with medium priority.

High priority: retrieval of data from shared memory

Medium priority: communications task
Low priority: thread collecting meteorological data

7 - 23
The MARS Pathfinder Problem (4)
“Most of the time this combination worked fine.

However, very infrequently it was possible for an interrupt to occur that caused the
(medium priority) communications task to be scheduled during the short interval
while the (high priority) information bus thread was blocked waiting for the (low
priority) meteorological data thread. In this case, the long-running communications
task, having higher priority than the meteorological task, would prevent it from
running, consequently preventing the blocked information bus task from running.

After some time had passed, a watchdog timer would go off, notice that the data
bus task had not been executed for some time, conclude that something had gone
drastically wrong, and initiate a total system reset. This scenario is a classic case of
priority inversion.”
7 - 24
Priority Inversion on Mars
Priority inheritance also solved the Mars Pathfinder problem: the VxWorks
operating system used in the pathfinder implements a flag for the calls to mutex
primitives. This flag allows priority inheritance to be set to “on”. When the
software was shipped, it was set to “off”.

The problem on Mars was corrected

by using the debugging facilities of
VxWorks to change the flag to “on”,
while the Pathfinder was already on
the Mars [Jones, 1997].

7 - 25
Timing Anomalies

7 - 26
Timing Anomaly
Suppose, a real-time system works correctly with a given processor architecture.
Now, you replace the processor with a faster one.
Are real-time constraints still satisfied?

Unfortunately, this is not true in general. Monotonicity does not hold in general,
i.e., making a part of the system operate faster does not lead to a faster system
execution. In other words, many software and systems architectures are fragile.

There are usually many timing anomalies in a system, starting from the
microarchitecture (caches, pipelines, speculation) via single processor scheduling
to multiprocessor scheduling.

7 - 27
Single Processor with Critical Sections
Example: Replacing the
processor with one
that is twice as fast
leads to a deadline
miss.

7 - 28
Multiprocessor Example (Richard’s Anomalies)
Example: 9 tasks with precedence constraints and the shown execution times. Scheduling
is preemptive fixed priority, where lower numbered tasks have higher priority than higher
numbers. Assignment of tasks to processors is greedy.
optimal
schedule on a
3-processor
architecture

7 - 29
Multiprocessor Example (Richard’s Anomalies)
Example: 9 tasks with precedence constraints and the shown execution times. Scheduling
is preemptive fixed priority, where lower numbered tasks have higher priority than higher
numbers. Assignment of tasks to processors is greedy.
optimal
schedule on a
3-processor
architecture

slower on a
4-processor
architecture!

7 - 30
Multiprocessor Example (Richard’s Anomalies)
Example: 9 tasks with precedence constraints and the shown execution times. Scheduling
is preemptive fixed priority, where lower numbered tasks have higher priority than higher
numbers. Assignment of tasks to processors is greedy.
optimal
schedule on a
3-processor
architecture

slower if all
computation
times are
reduced by 1!

7 - 31
Multiprocessor Example (Richard’s Anomalies)
Example: 9 tasks with precedence constraints and the shown execution times. Scheduling
is preemptive fixed priority, where lower numbered tasks have higher priority than higher
numbers. Assignment of tasks to processors is greedy.
optimal
schedule on a
3-processor
architecture

slower if
some
precedences
are removed!

7 - 32
Communication and Synchronization

7 - 33
Communication Between Tasks
Problem: the use of shared memory for implementing communication between
tasks may cause priority inversion and blocking.

Therefore, either the implementation of the shared medium is “thread safe” or

the data exchange must be protected by critical sections.

7 - 34
Communication Mechanisms
Synchronous communication:
 Whenever two tasks want to communicate they must be synchronized for a
message transfer to take place (rendez-vous).
 They have to wait for each other, i.e. both must be at the same time ready to do
the data exchange.

 Problem:
 In case of dynamic real-time systems, estimating the maximum blocking time
for a process rendez-vous is difficult.
 Communication always needs synchronization. Therefore, the timing of the
communication partners is closely linked.

7 - 35
Communication Mechanisms
Asynchronous communication:
 Tasks do not necessarily have to wait for each other.
 The sender just deposits its message into a channel and continues its execution;
similarly the receiver can directly access the message if at least a message has
been deposited into the channel.
 More suited for real-time systems than synchronous communication.
 Mailbox: Shared memory buffer, FIFO-queue, basic operations are send and
receive, usually has a fixed capacity.
 Problem: Blocking behavior if the channel is full or empty; alternative approach is
provided by cyclical asynchronous buffers or double buffering.

sender receiver
mailbox
7 - 36
Example: FreeRTOS (ES-Lab)

7 - 37
 Example: FreeRTOS (ES-Lab)
Creating a queue:

returns handle to the maximum number of items that the queue the size in bytes of
created queue being created can hold at any one time each data item

Sending item to a queue:

a pointer to the
data to be copied
into the queue
returns pdPASS if
item was successfully
the maximum amount of time the task
added to queue
should remain in the Blocked state to wait
for space to become available on the queue

7 - 38
Example: FreeRTOS (ES-Lab)
Receiving item from a queue:
a pointer to the
memory into which
the received data
returns pdPASS if data
will be copied
was successfully read
the maximum amount of time the task
from the queue
should remain in the Blocked state to wait
for data to become available on the queue

Example:
 Two sending tasks with equal priority 1 and one receiving task with priority 2.
 FreeRTOS schedules tasks with equal priority in a round-robin manner: A blocked
or preempted task is put to the end of the ready queue for its priority. The same
holds for the currently running task at the expiration of the time slice.

7 - 39
Example: FreeRTOS (ES-Lab)
Example cont.:

sender 1
queue receiver
sender 2

7 - 40
Communication Mechanisms
Cyclical Asynchronous Buffers (CAB):
 Non-blocking communication between tasks.
 A reader gets the most recent message put into the CAB. A message is not
consumed (that is, extracted) by a receiving process but is maintained until
overwritten by a new message.
 As a consequence, once the first message has been put in a CAB, a task can never
be blocked during a receive operation. Similarly, since a new message overwrites
the old one, a sender can never be blocked.
 Several readers can simultaneously read a single message from the CAB.

writing reading

7 - 41