Real-Time Operating Systems: Part 1: Mars Pathfinder 1997

Real-Time Operating Systems: Part 1
Mars
Pathfinder
1997
Industrial robot 2006
Design & Analysis for Embedded & Time-Critical Systems

Dr. Tom Clarke
tjwc - 10-Feb-09 Real-Time Operating Systems 1.1

Aims & Objectives
 Aims  Objectives
 Learn how to write application  Write, debug & test time-critical
code for time-critical embedded application code for ARM7
systems under an RTOS microprocessor under FreeRTOS
 Understand concurrent  Implement high-level concurrent
programming problems and system design using multiple
solutions tasks with semaphores, message
 Choose appropriate RTOS for queues and event flags for inter-
given application task communication.
 Understand different scheduling  Determine feasible schedules
methods and how they enable using extended RMA
hard deadlines to be met.  Analyse systems for livelock &
 Understand RTOS deadlock issues.
implementation  Contrast different solutions to
priority inversion.
 Compare and contrast different
RTOS implementations (e.g.
FreeRTOS & MicroC/OS-II)

Course Outline
1.1 Introduction PART 1 PART 2

Tasks 2.1 Interrupts & Exceptions
1.2 Task Control in FreeRTOS Hardware
Task states Background/foreground systems
FreeRTOS API Interrupts vs tasks
1.3 Shared Data Access 2.2 RTOS Task Lists
1.4 Semaphores Linked List implementation
Theory and applications Bit-mapped task list implementation
1.5 Message Queues 2.3 Context Switching
Theory and applications AVR example
1.6 Synchronisation Source code
Theory and applications 2.4 Timing Functions
1.7 Scheduling Theory Clock Tick
Priority scheduling Task Delay implementation
Round-robin scheduling 2.5 RTOS Objects
RMA, extended RMA, & deadlines Semaphores
1.8 & 1.9 Scheduling Problems Message Queues
Deadlock, starvation & livelock
Priority inversion 2.6 Writing an RTOS

Coursework
 Use LPC2138 microprocessor & Keil development tools

 Hardware is available and easy to use
 Excellent simulation of all hardware + peripherals from any PC
 Development system is free to download.
 FreeRTOS
 GNU Public License (GPL) RTOS free to use, good for 32 bit systems
 API includes semaphores, message queues, etc, all with timeouts.
 Allows priority & round-robin scheduling, dynamic priorities
 Still under development – small feature-set
 Coursework
 (1) Week 2. Introduction to FreeRTOS API (2 hours) – not assessed
 (2) Week 3-7. Online tests – Graded but not assessed
 (3) Week 7-11. Mini-Project (18 hours) - assessed

Resources
 Textbooks:
 Qing Li – Real-Time Concepts for Embedded systems 2003
 Clearly written, excellent review of all the theory
 No exercises
 £25
 Jean Labrosse - MicroC/OS II – The Real-Time Kernel (2nd edition)
 Less good theory, but good introduction to RTOS
 Excellent line-by-line description of MicroC/OS II
 C Pocket Reference (Peter Prinz) £5.50. Good concise reference to C.
Not required.
 Web resources:
 www.freertos.org
 Good introduction to practical RTOS principles and design – the FreeRTOS
source code is NOT well documented, but the API guide is good.
 www.its.strath.ac.uk/courses/c/
 One of many web references for the C language – better than most.
 Course web pages: https://intranet.ee.ic.ac.uk/t.clarke/rtos/

Language Prerequisites
#include “sysdefs.h”
 All RTOS we consider are written #define NUMTASKS 10
in C. #define MAXPRIO (NUMTASKS-1)
 This course assumes you are
familiar with C syntax
 Pseudocode will be written using #define portEXIT_SWITCHING_ISR( SwitchRequired ) \
C constructs if( SwitchRequired ) \
 RTOS source code makes use of { \
C macros to implement simple vTaskSwitchContext(); \
operations } \
 Macros use textual expansion to } /*this closing brace must match with { in ENTER macro*\ \
provide similar feature to functions portRESTORE_CONTEXT();
but without time overhead of
function call #if( configUSE_16_BIT_TICKS == 1 )
 RTOS make use of C conditional typedef unsigned portSHORT portTickType;
compilation to customise code #define portMAX_DELAY ( portTickType ) 0xffff
 C preprocessor references: #else
 Introduction in C web reference on typedef unsigned portLONG portTickType;
previous slide #define portMAX_DELAY ( portTickType ) 0xffffffff
 Comprehensive reference #endif
http://en.wikipedia.org/wiki/C_preprocessor

Language Prerequisites (2)
 RTOS implementation is based on objects (tasks, semaphores, etc) which are
defined by a C structure which implements an object control block. Control
blocks are invariably accessed via pointers.
 So a newly created task will be referenced via a pointer to its task control block
 In FreeRTOS these pointers have type void * (pointer to anything). No type checking!
 Void * pointer is given type name xTaskHandle
 RTOS internals are full of pointers between structures
 C uses consistent but very confusing syntax for describing pointers &
pointer types. Revise/learn this on a "need-to-know" basis.
 You may need to read about this at some time during the coursework when you get
confused. Depending on your background try one of:
 2 page C reference card (summary of syntax will not help understanding)
 C FAQ (Ch 4 on pointers). If you can answer these questions you don't need to read
further!
 C Pocket reference (on textbook slide). Good concise reference not for the beginner.
 Great intro to pointers & local memory, mostly language-independent but with
examples in C from Nick Parlante Stanford. 31 pages, but comprehensive. Explains
pointer diagrams etc. Good for those new to pointers, but fast.
 Long (53 pages) tutorial (Jensen) on pointers, arrays & memory alloc in C, as above
but longer.

Jargon used in these lectures
 RTOS – Real-Time Operating System

 Kernel – RTOS code that implements the API & controls task
switching
 API – Application Programming Interface (to an RTOS)
 RTOS port – version of RTOS for specific CPU/compiler
 RMA – Rate Monotonic Analysis
 EDF – Earliest Deadline First (scheduling)
 PIP – Priority Inheritance Protocol
 CPP – Ceiling Priority Protocol
 PCP – Priority Ceiling protocol
 TCB – Task Control Block (SCB – semaphore control block etc)

Lecture 1: Introduction
“I love deadlines. I like the whooshing sound they make as they fly by.”
Douglas Adams
 What is a Real-Time Operating  Basic framework

System?  Work to be done is split into tasks
 Controls CPU and resource  Each task has a state: ready or
allocation to application software blocked
 Enables programs to be written  RTOS controls which task runs
easily which interact with time- when
critical hardware  Called scheduling
 Allows "hard deadlines" to be  Tasks have priorities chosen so
guaranteed. that hard deadlines are met
 Typically used for small  Real-Time  add capabilities to
embedded systems meet hard deadlines
 May be used for very complex  Windows can't do this
systems – e.g. spacecraft

Multitasking vs true concurrency
 Normally a single CPU runs multiple programs (called tasks).

 Multitasking - Moving rapidly between different tasks - gives
the illusion that all are executing concurrently & independently.
Task States
 Tasks in a multi-tasking system can be suspended by the RTOS as
on previous slide, even though they are ready to run.
 Tasks may suspend themselves, e.g. by sleeping till a specific
future time or blocked till a given future event
 A blocked or sleeping task cannot be scheduled to run by the RTOS
until it has been woken up (unblocked)
 Every task has a priority. The RTOS will schedule the highest
priority task that is ready (i.e. not sleeping or blocked).
 The application programmer must assign a priority to each task
State Sub-state description
Running Only one task can be running at one time

READY
Ready-to-
All others are waiting to be scheduled
run
Task is waiting for fixed time – will be woken by system
Sleeping
BLOCKED clock-tick
Event Task is waiting for event to happen – will be woken by
Waiting event
Multi-tasking issues for RTOS
 How are tasks scheduled (when does execution need to switch)?

 Lecture 1.2 - task control - shows how tasks are created and can themselves
provoke task switches by going to "sleep".
 Lectures 1.3 & 1.4 describe the most basic mechanisms - semaphores and
message queues – that mediate event-based task switching.
 How is task switching implemented?
 This is the key question for any operating system. In Part 2 we will look in detail
about how this is done in two RTOS - FreeRTOS and MicroC/OS-II
 Key to understanding implementation is the role of interrupts in RTOS – Lecture 2.1
 How can deadlines be met?
 There is theory on different scheduling methods that guarantee real-time
response – so called "hard deadlines"
 1.7 looks at the theory, 1.8 discusses situations where performance is bad,
how to recognise them and how to cure them.

A Simple real-time system
 The LPC2138 boards you will use for practical work have
keys, and LCD, and both digital-to-analog output and
analog-to-digital input.
 One real-time task is to ensure that key-strokes are
processed and the LCD updated within 50ms. Anything
slower than 50ms is a noticeable delay and not acceptable.
Any time between 0 and 50ms is OK.
 A Task is implemented by a function with an infinite loop.
 In these lectures we will use C language with pseudocode
description of operations to illustrate code
 Variables and functions will use Hungarian notation, where the type
is indicated by prefix characters in name.
 This is difficult at first, but easy to get used to and makes understanding
code easier.

Task pseudocode
pv=>pointer to void
v=>void (no In C pointer to nothing means
return value) pointer which can point to anything
void vKeyHandlerTask( void *pvParameters )

{
/* Key handling is a continuous process and as such
the task is implemented using an infinite loop (as most
tasks are). */
for( ;; )
{
[ Suspend waiting for a key press ] Square brackets
[ Process the key press ] indicate
} pseudocode
}

Another task
 To make this system more complex, suppose there is another task

which performs A to D conversions, sampling the input voltage at
regularly intervals and taking appropriate action
void vControlTask( void *pvParameters )
{
for( ;; )
{
[Suspend waiting for 2ms since the start of the previous cycle ]
[ Sample the input ]
[ Filter the sampled input ] Require sampling accuracy of
[ Perform control algorithm ] 500us – deadline for this task
[ Output result ] is therefore 500us after timer
} event which initiates sampling
}

Execution Trace
 The way in which these two tasks behave can be analysed by looking at
an execution trace of the system
 The idle task is added by the RTOS to ensure that something is executing even
when the application tasks are both suspended
 The control task must be higher priority since has shorter deadline
 500us vs 50ms

Execution trace details…
a) At the start neither of our two tasks are able to run - vControlTask is waiting for the
correct time to start a new control cycle and vKeyHandlerTask is waiting for a key to be
pressed. Processing time is given to the idle task.
b) At time t1, a key press occurs. vKeyHandlerTask is now able to execute—it has a higher
priority than the idle task so is given processing time.
c) At time t2 vKeyHandlerTask has completed processing the key and updating the LCD. It
cannot continue until another key has been pressed so suspends itself and the idle task is
again resumed.
d) At time t3 a timer event indicates that it is time to perform the next control cycle.
vControlTask can now execute and as the highest priority task is scheduled processing
time immediately.
e) Between time t3 and t4, while vControlTask is still executing, a key press occurs.
vKeyHandlerTask is now able to execute, but as it has a lower priority than
vControlTask it is not scheduled any processing time.

… Cont’d
f) At t4 vControlTask completes processing the control cycle and cannot restart until the
next timer event—it suspends itself. vKeyHandlerTask is now the task with the highest
priority that is able to run so is scheduled processing time in order to process the previous
key press.
g) At t5 the key press has been processed, and vKeyHandlerTask suspends itself to wait
for the next key event. Again neither of our tasks are able to execute and the idle task is
scheduled processing time.
h) Between t5 and t6 a timer event is processed, but no further key presses occur.
i) The next key press occurs at time t6, but before vKeyHandlerTask has completed
processing the key a timer event occurs. Now both tasks are able to execute. As
vControlTask has the higher priority vKeyHandlerTask is suspended before it has
completed processing the key, and vControlTask is scheduled processing time.
j) At t8 vControlTask completes processing the control cycle and suspends itself to wait for
the next. vKeyHandlerTask is again the highest priority task that is able to run so is
scheduled processing time so the key press processing can be completed.

Simple Real-Time Application Design –
“outside-in” approach
 Decompose computation into
multiple tasks.
 Move from peripherals
inwards, specifying a
separate task for each
independent I/O device and LCD
adding extra tasks as
necessary to perform Key
T1
associated computation control
 Additional tasks may not be
needed, e.g. previous
example uses just two tasks T2
(dotted lines)
 Good design uses minimum D/A
A/D
number of tasks necessary output
input
to represent concurrent
operations

Real-Time Task Structure
 In a normal OS tasks often run
continuously without blocking till
endpoint.
 In an RTOS typically tasks will Task()
run in response to an event, and
then block until the next event {
happens [ initialise ]
 Real-time tasks spend most time
blocked for (;;) {
 Most real-time tasks run forever [ wait for event ]
 All tasks must block (except the
lowest priority task) in order to
[ process event ]
allow lower priority tasks to run. [ signal other tasks ]
 Total CPU utilisation must be <
100%
}
 Lowest priority Idle Task may run }
continuously "soaking up" any
spare CPU
 Avoids special case of no task
running

Real-Time System Design: Summary
Design Lecture
1.7
application specify determine
specification application task
and deadlines tasks priorities
Implementation Choose & write write

configure startup application
RTOS task tasks
FreeRTOS for coursework Next Lectures

See Part 2 for other OS lecture 1.3 - 1.6

Summary
 Real-time computation can be implemented via multitasking where

tasks share CPU execution time with a relatively fine grain
 Tasks have STATE:
 READY: Running, Ready (to run)
 BLOCKED: Sleeping, Event-waiting
 In general more than one task may be READY – which task is
actually run (scheduling) will be considered later
 In RTOS most tasks spend most of time BLOCKED
 For simple problems scheduling may be ignored
 In many cases all possible schedules will work OK
 Real-time application design splits the computation into multiple
tasks based on control of I/O devices
 In typical embedded system only one application runs
 RTOS may be optimised for this application by eliminating
unnecessary functions or reserved memory
Lecture 2: Task implementation in FreeRTOS
Now the earth was formless and empty. Darkness was on the surface of the deep.
Genesis 1:2
 How to use FreeRTOS
Startup & task creation
 Startup task
 Stacks
 Timing functions
Delaying the current task
 Controlling the scheduler
Changing task priorities
Suspending and restarting the multi-tasking

FreeRTOS
 FreeRTOS is a simple Gnu Public License (GPL) real-time OS written in C which

is highly portable and supports:
 Prioritised scheduling
 Round-robin scheduling for equal timeslicing tasks with same priority
 Dynamic creation & deletion of tasks
 Semaphores, message queues, etc.
 Dynamic task priority changing
 Enables many more complex scheduling operations
 FreeRTOS Kernel implements FreeRTOS API (application programming
interface)
 Advantages
 Has been ported to many different microprocessors and compilers
 Very simple and regular Kernel code based on lists and queues.
 Very flexible and scalable – suitable for large systems or small
 Disadvantages
 Not as efficient as some other RTOS (e.g. MicroC/OS-II)
 Not very well documented
 Minimal set of features implemented so far

FreeRTOS tasks
 In FreeRTOS a task is  All FreeRTOS tasks are created

implemented using dynamically.
 A C function with an infinite loop  The FreeRTOS startup is initiated
 This can call other functions as by a single startup function.
necessary to implement the task
 The function can have
 Startup sequence:
parameters passed when the  Initialise hardware
task is created, so that multiple  Create at least one task
tasks can share the same code.
 Start the RTOS scheduler
 A (private) stack on which to
 At this point control moves from
store local variables the startup function to the RTOS
 Created automatically when the scheduler which will run the
task is created created task(s).
 A task control block (TCB) which  Additional tasks can be created
contains all the task-specific from running tasks
information  Often the number of tasks is
 Pointer to this is returned as a known in advance and all are
task handle created from the startup function.
 Can be used by subsequent
task-control functions

Task Creation
#include "freertos.h" /*FreeRTOS type definitions etc */
Constants in C use /* constants */

#define #define mainLCD_STACK_SIZE 100 /* determines stack size */
Note constant naming #define mainLCD_TASK_PRIORITY 4 /*determines priority */
convention:
moduleNAME int main(void)
{
xTaskHandle task1; /* variable to store task handle */
portBASE_TYPE x; /* variable to store return value from task */
x = xTaskCreate(
vLcdDriveTask, /*task function*/
"LCD", /* name for debugging */
Task handle optionally
mainLCD_STACK_SIZE,
returned in a variable. NULL, /*pointer to parameters, not used in this task so NULL*/
Note & makes pointer to mainLCD_TASK_PRIORITY,
allow call-by-reference &task1 /* replace by NULL if task handle not required */
);
Return value is either
pdPASS or an error code if (x!=pdPASS) hwLcdFatalError("Task creation failed");
(see projdefs.h)
Task Function definition
void vLcdDriveTask(void * pvParameters); Function prototype needed if function
definition is after its use
int main(void)
{
[create the task]
}
void vLcdDriveTask(void *pvParameters)

{
Be careful to check storage of local variables –
[define local variables]
if big need to increase stack size
pvParameters=pvParameters; /*stops compiler warning*/
[initialise variables used in this task]
Note typical task structure: is
for (;;) { /*loop forever*/ asleep most of time, uses
if [characters waiting to be displayed] { CPU only when doing
[write characters to the LCD] something.
}
vTaskDelay(10); /* wait 10 clock ticks */ DON’T put wait-for-data
} loops in tasks
}
#include "hwdefs.h" /*hardware-specific definitions */ RTOS Startup
#define mainKBD_TASK_PRIORITY ( tskIDLE_PRIORITY + 2 ) Good practice to
#define mainLCD_TASK_PRIORITY ( tskIDLE_PRIORITY + 4 ) define task priorities
#define mainADC_TASK_PRIORITY ( tskIDLE_PRIORITY + 3 ) relative to idle task
priority (which is 0)
int main( void )
{
prvSetupHardware(); Setup app-specific hardware
vlcdStartLcdTask( mainLCD_TASK_PRIORITY); Task creation details have been put

in extra functions, including error
vkbdStartKbdTask( mainKBD_TASK_PRIORITY); check. Each task has its own C file,
vadcStartADCTask( mainADC_TASK_PRIORITY); indicated by the prefix)
/* Now all the tasks have been started - start the scheduler.*/
vTaskStartScheduler(); After scheduler starts it will normally

run forever – so a return is an error
/* Should never reach here! */
hwLcdFatalError("Kernel terminated!"); /*good practice to check this*/
return 0;
}
Stack use in RTOS
 A running computer program requires stack task1
 Store local variables, return addresses Unused
stack
 Size depends on program, can be large
 For non-recursive programs can compute size. scan()
Normally just make an over-estimate. checkKeys()
 Every task is an independently running
program and needs its own stack. kbdTask()
 In practice, it is too difficult to dynamically
change space allocated to stacks.
task2 Unused
 Fix stack-size on task creation
stack
 When a task is not running its context (all the
CONTEXT
CPU registers including PC & status register)
must be saved on its own stack. writeNibble()
 Must add CPU context size to required stack
lcdTask()
 Stack overflow is common cause of RTOS
bugs
Stack sizing for ARM7/Keil port
 FreeRTOS stack sizes are measured in number of stack items

 ARM7 is 32 bit so each item is 4 bytes
 Minimal stack by default is 100 items
 Always allow 17 items on stack for task context (17 registers)
 Leaves 83 items
 Stack use is determined by number of nested function calls
 Typically between 2 and 8 items per function call
 Difficult to calculate stack size precisely
 Consequences of stack overflow are disastrous!
 Determine minimum size by trial & error, then add safety margin
 Use instrumentation to check high water mark of stack actually used.
 FreeRTOS provides diagnostic functions – see coursework

FreeRTOS API – Task Control in Detail
 Task create/delete Call to
 xTaskCreate vTaskSuspend() Suspended Call to
 xTaskDelete vTaskSuspend()
 Task sleeping
 vTaskDelay() Call to Call to
 vTaskDelayUntil() vTaskSuspend() vTaskResume()
 Kernel control
Scheduled
 vTaskAllSuspend() READY RUNNING
 vTaskAllResume() Preempted
 portENTER_CRITICAL()
 portEXIT_CRITICAL() Event or
Tick Call to
 Task suspension blocking API
 xTaskSuspend(xTaskHandle h) BLOCKED function:
 xTaskResume(xTaskHandle h) waiting event vTaskDelay()
or timeout xSemaphoreTake
etc
Creation
 Task creation uses RAM

 Task Control Block
 Task Stack
 New task will be executed immediately on creation if high enough
priority
 Task Deletion frees RAM
 Programmer must ensure that all resources associated with task –
semaphores etc, are also recovered
 Programmer must ensure no tasks are left blocked on objects deleted
 Simple RTOS applications use static tasks, created at startup and
persisting forever
 Complex applications may spawn and delete tasks dynamically

Task delay - vTaskDelay
 Task sleeping is the most basic method for a task to temporarily
give way to lower-priority tasks
 Time is measured as number of system clock ticks, where the clock tick
is a fixed frequency signal derived from a timer.
 Task becomes BLOCKED and stays in that state for a given number of
system clock ticks, after which it is made READY.
 vTaskDelay( interval)
 Delays until interval ticks have passed
 Delay time t is (interval-1)*TickPeriod < t < interval*TickPeriod
Task()
{
for (;;) {
[ do something ]
vTaskDelay(2); /* wait 2 clock ticks */
}
}
Task delay in detail
 Repeated calls to vTaskDelay(n) should produce delays of
n*TickPeriod if running time of task is small
Generally this can't be guaranteed due to preemption by other tasks
If exact timing is required, solutions are:
Increase task priority
Use the more complex vTaskDelayUntil()
System Ticks
Sleeping
D W D W D W D - TaskDelay(2);
Running W – Wakeup from tick
S
Ready S - Scheduled
Task is ready, but not scheduled due to a higher priority task

Task Delay – xTaskDelayUntil()
 Purpose – delay execution until a specific time to ensure accurate
periodic execution.
/* Perform an action every 2 ticks. */

void vTaskFunction( void * pvParameters )
{
portTickType xLastWakeTime;
const portTickType time = 2;
/* Initialise the xLastWakeTime variable with the current time. */
xLastWakeTime = xTaskGetTickCount();
for( ;; ) {
/* Wait for the next cycle. */
vTaskDelayUntil( &xLastWakeTime, time );
/* Perform action here. */ xLastWakeTime is automatically
} updated by each call.
}

Kernel Control
 FreeRTOS has two ways for a task to ensure
temporarily private access to data or hardware
resources.
Critical Sections
 A section of code requiring this is called a
critical section
 1. Switch off all interrupts (interrupt-lock)
 Advantages portENTER_CRITICAL();
 Nothing can preempt the current task
 No ISR will run [Private access to data]
 Fast to implement
 Disadvantages
 Long times will impact ALL interrupt times portEXIT_CRITICAL();
 Therefore only useful for short critical sections
 2. Disable scheduling (preemption-lock)

 Advantages
 Interrupts will still be processed
vTaskSuspendAllTasks();
 Tasks not allowed to preempt current task
 Disadvantages [private access to data
 Slower to implement shared with other task(s)]
 Can't be used to protect data from interrupt
access
vTaskResumeAllTasks();

Nesting critical sections
 The use of functions to enter & exit critical
sections raises one subtle but important issue.
f1()
What happens when critical sections are
{
nested?
portENTER_CRITICAL();
 The desired behaviour is that the nested f2();
portEXIT_CRITICAL() or TaskResumeAll() /* want this still to be critical */
commands do NOT exit the critical section. portEXIT_CRITICAL();
This must happen only on the outermost exit. /* no longer critical after
 This allows functions define critical sections to outermost exit */
call other functions which define critical }
sections internally.
 For example RTOS functions may be called f2()
which themselves define critical sections. {
 Note that blocking RTOS functions, like portENTER_CRITICAL();
vTaskDelay(), must never be called inside /* nested critical section */
critical sections. portEXIT_CRITICAL();
 FreeRTOS critical section commands are all }
nestable in this way – but check RTOS
documentation before assuming this for other
RTOS
Task priorities & scheduling
 The scheduler uses task priorities to determine which task to run whenever multi-
tasking is enabled (ie not in a critical section)
 The scheduler will ensure that the currently running task is always the highest priority
READY task.
 Making ready a high priority task will therefore cause preemption of the current task.
 If there are multiple READY tasks of equal highest priority the scheduler will time-slice
between them
 See slide 1.123
 Priorities can be inspected and changed dynamically with API functions as below.
 A task can change its own priority without storing its task handle, by using NULL as first
parameter.
{
xTaskHandle *xh1; /* variable to store task handle of newly created task*/
int uxCurrPriority = uxTaskPriorityGet(NULL); /*store priority of this task*/
/*create new task, handle xh1, priority 1 more than this task*/
xCreateTask(vT1Code, "T1", 100, NULL, uxCurrPriority+1, &xh1 );
xTaskDelay(2); /*wait between 1 & 2 clock ticks*/
vTaskPrioritySet( xh1, uxCurrPriority-1 ); /*decrease priority of new task*/
}
Determining task priorities
 In real-time system assume normal state for all tasks is blocked!

 Allows other tasks to execute
 A task that runs continuously will prevent lower-priority tasks from
executing
 When a task executes it will delay execution of all lower-priority
tasks for as long as it is running.
 Drtermine task priority according to:
 a) For how long (max) they execute before blocking. Long execution time
=> low priority
 b) How much delay can they tolerate between being ready-to-run and
running. Long delay Ok => lower priority
 Often task priority does not matter very much. When it does we will
learn how to quantify delays later.

Lecture 2: Summary
 Task create/delete  Kernel is all the RTOS code which implements the API
 xTaskCreate()  A single startup function creates tasks and then calls the
 xTaskDelete() FreeRTOS scheduler to initiate multi-tasking.
 Task sleeping  Tasks have states: RUNNING, READY, BLOCKED,
 vTaskDelay()
SUSPENDED. (SUSPENDED is special case of
 vTaskDelayUntil()
BLOCKED requiring explicit Resume() to restart)
 Kernel control
 The FreeRTOS scheduler uses task priorities, with
 vTaskSuspendAll()
 xTaskResumeAll()
equal priority scheduling time-sliced between tasks.
 portENTER_CRITICAL() Tasks can be preempted when higher priority tasks
 portEXIT_CRITICAL() become READY.
 vTaskPrioritySet()  API functions exist to create, delete, delay tasks. Tasks
 uXTaskPriorityGet() are referenced via task handles.
 Task suspension  Critical sections can be made by temporarily stopping
 vTaskSuspend() interrupts, or disabling scheduling.
 vTaskResume()  The API contains delay functions which make tasks
sleep (block) for given number of clock ticks, or till a
specified clock tick.
 Tasks can dynamically control priorities of themselves,
or any other task where they know the task handle.

Review Questions 2
 A serial port driver task runs code of the form:

for (;;) { /*loop forever*/
while ( [ port hardware is not ready for next character ] ) ; /*busy-wait loop till
port is free*/
[ write next character to port ]
}
2.1 Rewrite this so that the busy-wait loop is removed and replaced by a task delay function.
2.2 Explain why the original code would be defective in a multitasking system if the task is given
a high priority relative to other system tasks (assume that a continuous stream of output
characters is available).
2.3 Contrast the performance (speed of character output) of the original code and the new code,
assuming no other tasks in the system? What is the maximum speed the new code can
attain in characters per ClockTickPeriod?
2.3 Write a complete FreeRTOS system with a task which will update a 24 hour clock display
every second, assuming that the display can be written to by a function vWriteToDisplay(
int houtrs, int minutes, int seconds); which you are given. vWriteToDisplay runs without
blocking and takes 100us to complete. Discuss what priority should your task have relative
to other system tasks. What percentage of total CPU time will it use?

Lecture 3: The Shared Data Problem
Collecting data is only the first step toward wisdom, but sharing data is the
first step toward community.
Henry Louis Gates Jr.
 This lecture considers why critical sections of code are required

to ensure correctness when accessing shared data
 Shared data problems are at the heart of why concurrent systems
are more difficult to write than sequential programs
 This will be in part revision for ISE students who have covered
concurrent systems
 Material in this lecture is not specific to real-time systems.

How to think about concurrent programming
 Lecture 1 introduced scheduling in real-time operating

systems.
 This is an important topic which relates to the timing of real-time
systems
 We will deal with this in detail later
 In this lecture we will on purpose make minimal assumptions
about the way that tasks are scheduled
 Separate functionality & timing
 Ensure functionality is correct for any scheduling strategy
 Later we will consider how scheduling can be adjusted to ensure time
deadlines are always met.
 This, in practice, is the only feasible way to write robust
concurrent code.
 RESIST TEMPTATION TO WRITE CODE WHERE SCHEDULING
CAN DETERMINE CORRECTNESS

Task execution interleaving
 In general tasks may be preempted at any

time and another task run. Task1 Task2
 We will not assume anything about the Time
scheduler
 Must ensure correctness for all possible A0 B0
execution traces
 Assume two distinct tasks may be arbitrarily B1
interleaved. Operations
 Technically we impose only a progression
requirement that all tasks that are READY
will eventually make progress A1 B2
 Interleaving can create problems. For
example even though B0 & B1 happen
immediately after each other in Task 2 they
may be separated in execution time by code A2
from Task 1.
Execution traces illustrate interleaving of tasks…
 Where data is shared between Task 1
& Task 2 this can cause errors A0B0A1B1A2B2
 Multiple execution traces  more A0A1A2B0B1B2
chance of bugs
A0A1B0B1A2B2
Etc…
Error Counting
 Problem
 Implement function RecordError() which can be called from multiple
tasks and counts the total number of times it is called.
 Single-threaded solution
static int prvErrorCount = 0; /* initialise to 0 */
vRecordError()
{ /* this function assumes overflow will never happen */
int x;
x = prvErrorCount;
prvErrorCount = x + 1;
return x;
}
 ErrorCount variable is shared data

RecordError() is not safe when multi-tasking
vRecordError()
 Note here that the two {
local x variables are int x;
separate x = ErrorCount;
[ Task 2 preempts
 Each task has a vRecordError()
task 1]
separate stack. {
 However the relative int x;
timing shown here x = ErrorCount;
means that two calls ErrorCount := x + 1;
}
result in ErrorCount
[ Task 2 blocks ]
only increasing by 1
 Error! ErrorCount := x + 1;
}
Task 1 Task 2

Curse of the infrequent error
Occasionally you hear someone say:

"Well my program works most of the time!".
This always sends shivers down my spine. Infrequent bugs
which cannot be reproduced are the most difficult to fix.
 The "shared data problem" is a classic example of an infrequent

bug. It may be very unlikely that a task will be preempted at
precisely the wrong time and so cause this bug. It may indeed
never happen in a prototype, only to emerge when a CPU of a
slightly different speed is used.
 If it CAN happen, it is an error.
 Because it will be difficult to debug when the program is running the
only realistic solution is to be very, very careful to ensure bugs of this
kind are designed out from the start.
 This is the main reason why concurrent systems programming
requires much more care than conventional programming

Atomic operations
 The solution to this problem is to recognise that the read and write
operations on prvErrorCount must be atomic (executed without
interruption) for correct operation. This can be enforced in an
RTOS by making the code a critical section
 Kernel will not allow task switch during critical section
static int prvErrorCount = 0; /* initialise to 0 */
Safe
called void vRecordError(void)
from { /* this function assumes overflow will never happen */
multiple int x;
tasks portENTER_CRITICAL;
x = prvErrorCount; Critical section creates
prvErrorCount := x + 1; atomic read-and-
portEXIT_CRITICAL; increment operation
}

Assignment statements are not atomic
 The code from the previous slide

can be rewritten to make it look
as though the ErrorCount update
is a single operation.
 Unfortunately this does not help. static int prvErrorCount = 0;
 On a Load/Store architecture the
memory read and write must be void vRecordError(void)
separate instructions and {
therefore can be interrupted in
portENTER_CRITICAL;
the middle.
prvErrorCount=prvErrorCount+1;
 Even on an architecture which
portEXIT_CRITICAL;
has a single instruction which
increments memory there is no }
guarantee this will be used by Critical section is needed
the compiler. because assignment
operation may not be
 Make sure all such operations are
atomic (depends on
inside critical sections for safety.
compiler)

Re-entrant Functions
static int prvErrorCount = 0;
 Functions which are safe to call from
multiple tasks are called re-entrant.
static int x;
 vRecordError() with a critical section
protecting the memory read/write is
re-entrant vRecordError()
{ /* this function assumes
 To be re-entrant a function must:
overflow will never happen */
 Store intermediate results on its stack,
not in static or global variables portENTER_CRITICAL;
 Ensure all atomic operations on static x = prvErrorCount;
or global variables or hardware are prvErrorCount := x + 1;
protected by critical sections portEXIT_CRITICAL;
 Only call other functions which are re- }
entrant
 NB – a function can always be made Critical section protects both x
re-entrant by enclosing its entire body & prvErrorCount so this is re-
in a critical section entrant.
 If the function is potentially long this NB why does x static here
solution is undesirable. mean less RAM use than x as a
 If function can BLOCK this is an error local (previous slides)?
Is printf re-entrant?
 You cannot assume the implementation will be re-entrant – printf
may use static storage for intermediate results which will be shared
between different concurrent function calls
 Even if this is OK, the results of printing out from two different tasks
may be that the individual characters printed are interleaved.
 This is usually not the desired behaviour
 In general do not assume that standard library functions are re-
entrant unless this is stated.
 You can always create re-entrant wrappers to non-re-entrant
functions:
unsigned int urand_safe(void)
{
int x; /* why must x be local here?*/
portENTER_CRITICAL;
x = rand(); /*library random number routine*/
portEXIT_CRITICAL;
return x;
}
Inconsistent Data Structures
 A common cause of the shared
MonitorTask() data problem is when a data
{ structure is updated inconsistently.
for (;;) {
In the code below ControlTask()
[ read temperatures ]
Temp1 = [ first tank temperature ] expects Temp1 & Temp2 to be
Temp2 = [ second tank temperature ] temperatures read in the same
vTaskDelay(100); iteration of MonitorTask().
}
}  This will not in general be the case
 Here Temp1, Temp2 form a data
structure which must remain in a
consistent state when it is read or
ControlTask() written.
{
for (;;) {  The two reads in ControlTask()
If (Temp1 != Temp2) [ sound a buzzer] must be atomic
[do other stuff]  The two writes in MonitorTask()
} must be atomic
}

Case study: Best Fit Memory Allocation
 Sophisticated RTOS require a memory management module which will

allocate memory dynamically to tasks as they require it, and accept back
memory which is no longer required (free).
 This module will control all the system free RAM (heap)
 NB – static & global variables are allocated by the compiler & not from heap
 Task stack memory is allocated from the heap when tasks are created.
 Memory management is not easy if arbitrary size blocks of memory can be
requested and freed, because the "pool" of available memory becomes
increasingly fragmented as time progresses.
 Best fit allocation is a simple method which has quite good performance
as long as blocks are not continually allocated and freed.
 Basic idea
 keep a list of all the currently free blocks of memory
 MallocWord( int n) returns an allocated block of size n wordsfrom this list on a
best-fit basis
 Free() Adds free block of memory back into the list.

Memory Allocation (2)
FreeList: next: next: next: NULL
Arraysize: 16 Arraysize: 8 Arraysize: 12
 Use a linked list of memory
blocks FreeList. Each list Free
node contains an array of n memory Free
bytes (the memory that can be Free memory
allocated) together with an memory
arraysize indication (set equal
to n) and pointer to the next
list node. 16 words
 Initially all free memory
(assumed contiguous) forms a
single node.
 Optimisation: store list sorted
by arraysize, smallest first

Memory allocation (3)
best fit block:
next: next: Old node has size field
changed and its free
Arraysize: 16 Arraysize: 10 memory is given to
requesting task.
Used by Free Note that the Freenode

task memory header is not touched by the
application and will be used
Free when the block is freed
next:
memory
Arraysize: 4 New node is created
which contains spare
Free space and is added to
memory FreeList
If best fit block in

FreeList is too big
Sequential code to allocate memory
Typedef struct {
Fnode *p; /*pointer to next node*/
int arraysize; /*size in words of memory block*/
int mem[0]; /*start of array of free words in the node*/
} Fnode;
Fnode *FreeList=NULL;
void *MallocWord( int n)
{
Fnode *q = NULL; /* return Null if no mem left */
Fnode *p = [ smallest node in freeList with
arraysize >= n, if one such exists ]
[ remove p from Freelist ]
If ( [ space left for another block in p mem array ] ) {
q = [ new Freenode structure of correct size ]
[ adjust arraysize field of p ]
[ insert q into Freelist ]
}
return p->mem;
}
Data Sharing Issues
 The shared data structure is the FreeList linked list. Operations

performed on this are:
 Working out the "best-fit" node – read
 Deleting a chosen node – read/write
 Inserting a new node – read/write
 Each of these operations must clearly be atomic.
 During allocation, in order to delete the chosen node efficiently, two
pointers must be kept to the node & the previous node.
 These will become out-of-date if any list-changing operation happens
between choosing the node and deleting it.
 Also, the best-fit node must not be chosen by any other task once it
has been determined and before it is deleted.
 Therefore finding best-fit node & deleting the best-fit node must be
atomic, however inserting a new node (if the node splits into two) can
be a separate (also atomic) operation.

Concurrent code to allocate memory
/* return a pointer to a block of memory size n words */
{ This
Fnode *p, *q = NULL; /* return Null if no mem left */ implementation
assumes that
TaskSuspendAll(); MallocWord() is
p = [ smallest node in freeList with never used in an
arraysize >= n, if one such exists ]; interrupt.
if (p != NULL) [ remove p from Freelist ];
TaskResumeAll(); What change
If ([ space left for another block in p mem array ]) { would have to be
q = [ new Freenode structure of correct size ]; made if it were?
[ adjust arraysize field of p ];
[ insert q into Freelist - atomic (see next slide) ];
}
if (p !=NULL) { /*check whether block was allocated */
return p->mem; /*if so, return pointer to first word of free memory */
} else {
return NULL; /* if not, return NULL */
}
Free list node insertion
[ insert q into Freelist - atomic ];
/* the insertion is very fast so switch off interrupts for critical section */
enterCRITICAL_SECTION();
q->next = Freelist;
FreeList = q;
exitCRITICAL_SECTION();

Lecture 3: Summary
 We can separate functionality, and timing (scheduling) issues in an RTOS.

 Define tasks so that they will function correctly regardless of scheduling
 Choose scheduling (see later) to ensure hard deadlines are met
 The execution trace interleaves operations from different tasks arbitrarily (but
we assume that all tasks able to progress will do so eventually).
 Functions which can be safely called from different tasks are called re-entrant.
 They must not rely on private use of hardware or static variables except inside critical
sections
 They must not call other non-re-entrant functions
 C Library functions (e.g. printf) are not generally re-entrant
 Data sharing between tasks leads to problems unless all atomic operations are
protected by critical section entry & exit
 Shared data structures must be left in a consistent state outside of critical
sections
 Use critical sections to encapsulate write operations on a data structure
 Use critical sections to ensure read of different parts of a data structure is consistent

Review Questions 3
3.1 In slide 1.55 explain why both the two reads AND the two writes
must be atomic by giving in each case an execution trace that
leads to an error otherwise.
3.2 In a priority-scheduled RTOS the highest-priority READY task will
always run. Suppose in the problem from slide 1.55 you may
assume that MonitorTask() is higher priority than ControlTask().
How does this change the necessary critical section code in either
task? Explain your reasoning.
3.3 Shared-data problems are important and a common source of
bugs in RTOS applications. Problem Sheet 1 contains further
examples.

Lecture 4: Semaphores & resource access
"We semaphore from ship to ship, but they're sinking, too."

Mignon McLaughlin
 The previous lecture showed how shared data structures in

memory need private access from tasks to maintain consistency
 Implemented via critical sections which enforce atomicity of
operations
 This is a brute-force way to enforce exclusive access. Switching
off task preemption (or, more drastically, interrupts) for long
periods of time is not feasible, since it blocks ALL other system
tasks
 We need a more selective way of blocking just the tasks that try
to use the shared resource
 This applies to many different types of resource: hardware, data
structure, software.
 The solution is to use semaphores

 Semaphores are provided by almost all RTOS as part of the API
(application program interface) together with the basic task creation &
delay functions.
 This lecture will examine:
 Why are semaphores useful?
 How do they work?
 What variants of sempahore can be found in different RTOS – what are the
advantages of different variants
 What are the typical problems using semaphores.
 When compared with use of critical sections, semaphores are
expensive:
 The semaphore operations typically take longer to execute than critical
section entry & exit
 The semaphores themselves require (a small amount) of RAM and increase
the size of the RTOS kernel itself
 RTOS will usually allow semaphore code to be removed from the RTOS
when it is not needed, saving code space.

Semaphore introduction
Blocked
waiting Holds S1
S1 token
S1 S2 S3
 The name is taken from analogy with railway signal semaphores,

used to ensure that AT MOST ONE TRAIN can run on a given
section of track.
 Here the shared resource is the section of railway track
 Binary semaphores have a single token which can be acquired
by a task. The task holding the token releases it back to the
semaphore, after which the cycle can repeat with another task.

Semaphore Implementation
 We need only keep track of whether the semaphore has the token
(state=1) or not (state=0).
 When a task waits on the semaphore either it is given the token
immediately (state0) or it blocks until the token is released by
another task.
 Tasks using the semaphore must call a semaphore wait function
first followed by a semaphore release or signal function.
SemaWait(Semaphore s) SemaSignal(Semaphore s)
{ {
if (s->state == 1) {Critical if ( [ s->waiters is empty ] ) {
s->state = 0; sections s->state = 1; /* give token back */
} else { } else {
[add current task to s->waiters] [wake up highest priority task in s->waiters]
[suspend current task] /* task we have woken up is implicitly given token */
} }
} /* if suspended another task will run */ /* the task woken up may preempt current task and */
} /* run immediately if higher priority than signal task */

Semaphore Usage
 There is no agreement on the names for the two basic Command Command
semaphore operations to acquire to release
 The common names are shown in the table – all make sense.
token token
 Typical FreeRTOS code shown below – with a TIMEOUT to
detect when tasks never get semaphore Wait Signal
Acquire Release
#include "semaphr.h" Take Give
xSemaphoreHandle s; Pend Post
#define TIMEOUT 100; /* max no of ticks to wait for sema */
Lock Unlock
Task1()
{
/* create the semaphore in just ONE task */
vSemaphoreCreateBinary( s); /* in FreeRTOS semaphore creation is managed via a macro */
for (;;) { Semaphore Wait includes optional timeout
if (xSemaphoreTake(s, TIMEOUT)==pdFALSE) [ handle timeout error ];
/* use shared resource */
if (xSemaphoreGive(s) == pdFALSE) [ handle multiple signal error – should never happen ];
}
}
Signal & Wait Paradigm
 The simplest use for a binary semaphore is unusual, because it does not protect a
resource.
 The semaphore acts as an RTOS primitive to synchronise a waiting task
WaitTask with a signalling task SignalTask. The semaphore use is illustrated in the
diagram
 For this application the semaphore must be initialised without a token
(state=0). If the RTOS does not allow creation like this an initial call to SemaWait()
immediately after creation (which will not block) will have the effect of changing
semaphore state as required.
0 WaitTask
SignalTask
B
SignalTask() WaitTask()
{ {
for (;;) { for (;;) {
Symbol for a binary
[ get next result ] [ wait on semaphore ]
semaphore, the
[ signal semaphore ] number indicates [do next action ]
} }
initial state
} }

One to Many Synchronisation Paradigm
 Sometimes multiple tasks must be synchonised with a single task.

 Some RTOS provide a SemaFlush() command which wakes up all
the semaphore's list of waiters.
 Otherwise a flush command can be simulated by reading the
number of waiting tasks and signalling that number of times to the
semaphore.
 FreeRTOS does not provide the facilities to do this in the API
 We will cover implementation under FreeRTOS in Part 2.
WaitTask1
flush 0
SignalTask WaitTask2
B
WaitTask3
Mutual Exclusive Access Paradigm
 Here the double-arrow indicates semaphore wait

followed by semaphore signal, with resource
access allowed in the section of code between
these two calls
 Note the initial value is 1
AccessTask1
1 Shared
AccessTask2
Resource
B
AccessTask3

Multiple Resource Exclusive Access
Paradigm
A counting semaphore can be used to control
access to N identical resources.
The initial value is set to the number of resources (here 2)
at any time at most 2 tasks have access to a token and so
can use a resource
Shared
AccessTask1
Resource 1
2
AccessTask2
C
Shared
AccessTask3 Resource 2

Recursive (nested) semaphore use
void f1(void)
 When semaphores control an exclusive
resource the same issue arises as for critical {
sections (slide 1.39). 1: SemaphoreTake( s);
 In this code the semaphore operations are f2();
executed in order 1,2,3,4. /* want this still to hold s */
 Operation 2 will cause the task to block 4: SemaphoreGive(s);
indefinitely. /* no longer holding s after
 Operation 3 will cause the semaphore to be outermost exit */
released when it should not be. }
 Some semaphore APIs allow nested use of
semaphore Take & Give operations by a task. void f2(void)
The inner operations (2 & 3) have no affect on {
semaphore state so that the semaphore token
2: SemaphoreTake( s);
is taken for the whole period of the outermost
/* uses shared resource */
section.
SemaphoreGive( s);
 This allows freer coding style with semaphores 3:
}
 Usually found on specialised "mutex" This code will not work
semaphores with normal semaphores

{
Fnode *q = NULL; /* return Null if no mem left */
Fnode *p ;
SemaphoreTake(FreeListSema);
p = [ smallest node in freeList with arraysize >= n, if one such exists ]
[ remove p from Freelist ]
SemaphoreGive(FreeListSema);
If ( [ space left for another block in p mem array ] ) {
q = [ new Freenode structure of correct size ]
[ adjust arraysize field of p ]
FreeBlock(q->mem);/*reuse Freeblock() code to insert q into FreeList*/
}
return p->mem; Case Study:
}
Memory Allocation
Void FreeBlock( void *p)
{
Fnode *mcb = [ pointer to Fnode structure containing block p ];
SemaphoreTake(FreeListSema); This is correct, but
mcb->next = FreeList;
is it really a good
FreeList = mcb;
solution?
SemaphoreGive(FreeListSema);
}
When to create semaphores
 A semaphore used by, say, two tasks, must be created

before either task first uses it.
 In general not possible to know that one task executes before the other
 Solutions that rely on relative priority of the two tasks are bad
 subsequent performance tuning may reverse this and it is stupid to
require a condition on priorities when it is not really necessary.
 Best solution – create a semaphore in a startup task which is
guaranteed to run before the tasks which use the semaphore.
 This is special case of a more general rule:
 DON'T RELY ON RELATIVE ORDER OF OPERATIONS IN
DIFFERENT TASKS UNLESS THIS IS KNOWN FOR CERTAIN
 USE A SINGLE TASK FOR SEQUENCING WHERE NEEDED
 E.g. the startup task can create semaphores before it enables multi-
tasking
Semaphore Problems
 Semaphores provide a neat solution to many mutual exclusion problems.
However, they create their own troubles. Here is a list of the most
common semaphore-use bugs:
 Forgetting to take the semaphore. If just one task uses the shared resource
forgetting to take the semaphore there will be a potential shared-data bug.
 Forgetting to release the semaphore. This is not so difficult to find, since it
will probably cause the whole system to lock up waiting for the semaphore.
However it is easy to do.
 Taking the wrong semaphore. It is very easy to use the wrong semaphore in
semaphore calls and so get unpredictable (not always obviously wrong)
results.
 Holding a semaphore for too long. Other tasks waiting on the semaphore
will be blocked for as long as it is held and therefore may miss real-time
deadlines
 Nested semaphore calls. Typically a function which needs the semaphore
calls another which also needs the same semaphore. The exclusive access is
needed for the task, not function, so what is required is to keep the hold
throughout both functions, but the nested function will block when it tries to
claim the semaphore!
Summary of Semaphore Features
 Different RTOS will provide different selections of the following possible

enhancements of a basic binary semaphore
Counting Allow more than one semaphore token, implemented by a

state variable which can be initialised to any positive integer.
Binary semaphores are often implemeted as a special case of
counting semaphores (count = 1), since the code is identical.
Timeout Return from wait operation with error indication if blocked for
more than a given time – application task can then recover
from the error. (Zero timeout conventionally used to disable
this feature).
Flush Release all waiting tasks through a single operation

(semaphore state after flush is not defined – check RTOS
documentation to be sure)
Mutex A variable set of features useful when controlling mutually

exclusive access to a resource. This may include ability to
control task priorities so as to eliminate priority inversion
(see later), and recursive use (slide 1.78).

Lecture 4: Summary
Semaphore Wait/Signal is
 Semaphores can be used to: indicated by an arrow
 Enforce exclusive access to from/to the semaphore
resource – "Mutual Exclusion"
 Synchronise tasks 0 Binary semaphore
 Semaphores must be created by initialised to 0
the application before they are B
used
 Make sure creation is guaranteed
to be before use regardless of Binary semaphore
1
scheduling initialised to 1
 Binary semaphores are most B
basic function. Additional features
that may be added (any
combination) are:
 Counting 4 Counting semaphore
initialised to 4
 Timeout
C
 Flush
 Mutex (discussed in lecture on
scheduling)

Lecture 4: Review Questions
 See web – problem sheet 2

Lecture 5: Data Transfer & Message Queues
“Dogs come when they're called; cats take a message and get back
to you later.”
Mary Bly
 Unlike semaphores, message queues can carry data (messages)

from one task to another.
 Like semaphores, tasks can block on message queues and therefore
they can be used for task synchronisation in much the same way as
semaphores
 Message queues are however NOT used for exclusive access to a
shared resource
 This lecture will focus on different types of data transfer between
tasks and message queues as a solution to this problem.
 The implementation of message queues is a good deal more
complex than that of semaphores, and will be considered at high
level only here. Concrete implementations will be discussed in Part 2.

What is a Message Queue?
 A Message Queue is a dynamically created RTOS object which
allows messages to be sent between tasks.
 The queue has a first-in-first-out (FIFO) buffer which can contain any
number of messages from 0 up to a fixed limit.
 QueueReceive() – extract and return with the message at the front of
the queue.
 If queue is empty block until a message is written
 QueueSend() – write a message to the queue
 Blocking send – if queue is full block writing process until space is
available for write completion (with optional timeout).
 Non-blocking send – return immediately with an error indication if the
write could not complete due to lack of space in queue.
Task1 Task2 Task1 Task2
Non-blocking send Blocking send

Message queue Message queue
Implementation
Buffer of
Waiting queued Waiting Typical usage: sending
list of messages list of tasks never wait, there is
sending receiving only one receiving task in
tasks tasks message wait/process loop
Message delivered
msgsmsgs-1
State Receive Send Msgs Message delivered

Waiting Msgssize-1
Waiting Size = Message delivered
List List max Msgs=1, msgs0
length of
Queue
queue created Not
Empty Full
Empty Any 0 0 Empty
number
Not 0 0 1  msgs
Empty < size Message arrived
Message arrived
Msgs1
Msgs=size-1, msgssize
Full 0 Any size
number Message arrived
msgsmsgs+1
Message-queue data: to copy or not to copy
 Message queues may contain

complete messages, or pointers to Task1 Task2
data elsewhere.
 Some RTOS only allow pointers
This Queue
 Advantages of pointers contains
 Queue storage is fixed size pointers
 Message data can be arbitrary size
 Data copying is minimised
 Disadvantage of pointers
 Data pointed to must not be
overwritten by the source task until it
has been read from the queue and Data stored in queue is
processed by the destination task. copied twice: task to
This may be a long time after the data queue, then queue to task.
was sent. Data pointed to is only
 Care needed not to overwrite data copied once, directly
held in buffers to soon
between tasks

Interlocked one-way communication
Queue
length 1
 Special case of a message
queue length 1 is sometimes Task1 Task2
called a Mailbox
 Task1 sends a message to the
queue and then waits on the 0
semaphore.
B
 Task 2 will receive the
message, process it, and only
then signal the semaphore. Blocking send to a message
 Because the two tasks stay in queue length 1 will also provide
interlocked communication,
lock-step Task1 knows it can without need for a semaphore.
over-write buffer storage used
for the sent message any time Can you see why if the queue
after the semaphore wait ends. contains pointers to message
data the semaphore version
might be preferred?

Interlocked one-way communication (2)
 Pseudocode for this problem,
using a queue of pointers to
message data Task1()
 It does not matter whether queue {
send is blocking or non-blocking [ allocate buffer to store message ]
since semaphore ensures it will for (;;) {
never fail [ write next message into buffer ]
[ send pointer to buffer to queue q1]
 Note message is stored in buffer [ wait on sema s1 ]
in Task1, no need for another }
buffer in Task2
Startup() Task2()
{ {
[ Create queue q1, size = 1 pointer, for (;;) {
length = 1 ] [ Receive pointer to
[ Create binary semaphore s1, init 0 ] data from q1 ]
[ Create tasks Task1 & Task2 ] [ process data ]
[ start scheduler ] [ signal to sema s1 ];
} }

Interlocked one-way communication: (3)
details under FreeRTOS
void Task1(void *p) void Task2( void *p)
{ {
/* buffer for data */ char *pcx; /* pointer to data */
char *pcBuffer = malloc(16); for (;;) {
for (;;) { xQueueReceive(q1,&pcx,0)
[ put new data into pcBuffer ] [ process data using pcx ]
xQueueSend(q1, &pcBuffer,0); xSemaphoreGive(s1);
xSemaphoreTake(s1,0); }
}
pcx:
pcBuffer:
Note that 4 bytes (1 pointer) are

copied from pcBuffer to the
16 bytes queue and from the queue to pcx
allocated
by malloc Need to create s1,q1, Task1,
Task2 in a startup task

Interlocked two-way communication
 Often a client/server Queues

length 1
model of communication is
required where each
message sent has a reply.
 Two message queues of Task1 Task2
length 1 will implement
this and ensure that the
two tasks stay in lock-step

Interlocked two-way communication
Task1()
 Each task will block waiting {
for the other so both tasks run for (;;) {
 Each task can only process 1:[ generate next message ]
2:[ send message to queue q1 ]
messages when the other is
7:[ receive reply from queue s2 ]
blocked, so this interlocked }
communication will be slower
than non-interlocked
 By making either q1 or q2 of
length 2 it is possible to Task2()
{
speed up the system, by
for (;;) {
sending one message in 3:[ receive message from q1 ]
advance of the reply received 4:[ process message ]
so that one item is always 5:[ generate reply ]
buffered in the queue. 6:[ write reply to q2 ];
 Why must Task1 also be }
changed to enable this?

Non-interlocked one-way communication
Queue
length N
Task1 Task2
 Non-interlocked communication is implemented by a queue of length > 1.

 Task1 can send up to N messages before Task2 processes any of them.
 After that Task1 either blocks, or, as here, has a queue send error
 Using blocking send would make the two tasks weakly coupled.
 Queue operates as a FIFO buffer
 If queue send is blocking, and N is large, this is similar to the operation of
a pipe. However pipes are always character-oriented, and have OS
primitives that allow multiple characters to be sent and received.
 Suppose Task1 generates 1 message every 10ms, and Task2 processes
messages at an average rate of 200 per second.
 How large must the queue be to ensure no errors in Task1 if Task2 stops
processing messages for 100ms once every 2 seconds?

Queue Features
 Pointers only, or fixed size  Blocking or non-blocking Send?
messages?  If non-blocking Send the queue has one list
 FreeRTOS allows any fixed-size of blocked tasks waiting to receive a
message. message
 Queue must specify message length on  If blocking send the queue also has a list of
creation tasks blocked waiting to send.
 Send & Receive from queue uses
pointers to message storage – the  Timeouts allowed?
specified number of bytes is copied  Any blocking operation may have optional
to/from the queue timeout
 If queue itself contains pointers, Send &
receive functions must contain pointers  Tasks woken on FIFO or priority basis?
to pointers!  Priority scheduling means that normally if a
 Message order list of blocked tasks waits for an event, the
task woken when the event arrives is the
 First-in First-out (FIFO) – the normal HPT.
method
 This can result in high priority tasks hogging
 Last-in first-out (LIFO). Effectively, by all traffic and starving lower priority tasks.
sending a message LIFO you are  Alternative (less common) gives messages
making it the first message to be read & to tasks on a strict first-come first-served
therefore this is good for high priority basis.
messages. Note however that later
LIFO messages will displace earlier  Queue Broadcast/Flush?
ones at the head of the queue.  Wake up all tasks waiting to receive a
message with a single transmitted
message.

Lecture 5: Summary
 Message queues implement communication & synchronisation (execution

ordering) between tasks
 Basic functionality
 Single-ended – tasks block on reading if queu is empty
 Double-ended – tasks also block on writing if queue is full
 Can allow as option a non-blocking read (or write) API function
 Storage implementation options
 Messages may be fixed-length of variable-length.
 Storage for messages may be allocated by kernel or RTOS
 Messages may be copied or shared (queue contains pointers)
 Queue message order
 Strictly speaking queue is FIFO (first-in-first-out)
 Queues can allow LIFO (stack) or priority-based order
 Task wakeup
 Can be implemented FIFO (longest waiting gets message) or by priority
(highest priority gets message).
 Queue flush
 Deletes all outstanding messages in queue
 Surprisingly useful

Lecture 5: Review Questions
 See web – problem sheet 2

Lecture 6: Synchronisation
“If you don't get all the clocks synchronized when the leap
second occurs -- you could have potentially interesting effects.
The Internet could stop working, cell phones could go out.”
Geoff Chester
 Barrier synchronisation
Definition
Solutions
 Synchronisation Objects
Event Registers & Event Flags

Barrier Synchronisation
 This is the typical activity  1. When each task arrives at
synchronisation problem where any point A in the barrier, it must post
number of tasks need to be its arrival to the other tasks, and
temporally aligned so that they all wait
execute specific sections of code  2. When all tasks have arrived at
starting at the same time. A, all tasks are allowed to
 Found where tasks need to cooperate proceed from point B in the
in the solution of a problem barrier.
 In this case none can start until it is  The next few slides look at
known that all are ready to start
solutions
Barrier
A B
Task1
A B
Task2
A B
Task3
A B
Task4
Solution 1: Helper Task & Semaphores
 The first solution conceptually uses a helper task to count the number of tasks
that have arrived.
 Each task signals to a counting semaphore SemA on arrival, and then waits on another
binary semaphore SemB. The helper task loops waiting on the semaphore SemA,
incrementing a private count variable every time the semaphore is signalled.
 When the helper task has counted the correct number of SemA signals it exits the loop
and signals to SemB.
 All tasks must be woken, so if a flush operation on SemB is available it should be used.
 Otherwise a loop is necessary to wake up all the tasks through repeated signals.
 The helper task must be higher priority than that the signalling tasks if SemA is binary –
otherwise counts may be lost.
 Better solution, shown here, is for SemA to be counting semaphore.
 Still good idea to have Helper task high priority
Task1 SemA SemB Task1
0 Helper flush 0
Task2 Task2
Task
C B
Task3 Task3
 Rather than have a separate helper task, the highest priority of the
synchronising tasks (TaskH below) can serve as helper while it is waiting
at the barrier. If SemA is a counting semaphore it does not matter if
other tasks arrive first – the semaphore signals will be remembered.
 The two semaphores must be created somewhere before the barrier code
executes.
#define NSYNCH 3 /* number of tasks to
synchronise */ TaskX()
TaskH()
/*all other tasks to synchronise*/
/* highest priority task to synchronise */
{ {
……
/* barrier point A */ /* barrier point A */
for (count=0; count <NSYNCH-1; count++) { [ Signal to SemA ]
[ wait on SemA ] [ Wait on semB ]
} /* barrier point B */
for count=0; count < NSYNCH-1; count++) {
[signal to SemB ]
}
}
/* barrier point B */
……
Alternative solutions
 It seems rather contrived to use a helper task counting arrivals

 Ideally a semaphore could be used which allows a negative count
value -N. Only after N+1 posts will a task waiting on this semaphore
be woken.
 Some RTOS allow this – the implementation is identical to a normal
counting semaphore
 This eliminates the loop, but two semaphores are still needed.
 Alternatively use an RTOS construct which allows tasks to wait on
the conjunction (AND) of multiple condition variables can be used.
Each task to synchronise will set one of the constituent condition
variables and then wait on them all.
 See later this lecture

Rendezvous synchronisation
 A special case of barrier synchronisation is where two tasks need

to be synchronised. Straightforward solution uses two binary
semaphores – each task signals one semaphore and then waits on
the other one.
 Write code for this using the FreeRTOS semaphore API.
Task1 0
Sem1
B
Task2 0
Sem2
B

Event Flag Registers
 An Event Flag Register is a special set of boolean variables

managed by the RTOS
 typically 8 or 32 occupying one machine word of storage
 Think of these variables as representing a set of boolean conditions of
the system.
 Each variable can be set or reset independently by an API function
 Any number of tasks can update the same or different variables
 As system condition changes so variables can be updated by any task
with knowledge of the change.
 Tasks can wait on conditions (boolean expresssions) of the
variables.
 OR of arbitrary variables
 AND of arbitrary variables
 Since different variables can be controlled by different tasks one
common use is many-to-one synchronisation
Event Flag Example
/*Event Flag object Creation */ 7 6 5 4 3 2 1 0
/*Create 8 bits of event flags */
/*Each bit 7:0 represents one flag */
8 event flags
FlagsA = EventFlagCreate();
/* Changing value of flags */

/* 2nd parameter is always a bit mask which specifies which flags are set or reset */
/* Each bit of 3rd parameter specifies whether corresponding flag is 1 or 0 */
EventFlagChange(FlagsA, 0xFF, 0x00); /* set all flags to 0 */
EventFlagChange(FlagsA, 0x11, 0xFF); /* set flags 4 & 0 to 1 */
/* Waiting on flag conditions */

/* 2nd parameter is mask which specifies which flags are considered */
/* 3rd parameter specifies value required of each flag for wait to end */
EventFlagWaitAll( FlagsA, 0xF0, 0xF0); /* wait until flags 7,6,5,4 are all set */
EventFlagWaitAny(FlagsA, 0xF0, 0x30); /* wait until any of 7,6 is reset or 5,4 is set */

Cf Event Flags & Semaphore
 Sets of event flags allow wait on multiple variables

 Any number of tasks can wait on a given boolean proposition,
when this is true all tasks will be woken up together
 A future task waiting on the same proposition will not block (if the
system has not changed).
 This is different from a semaphore where even if it is flushed this will
not allow future tasks to proceed.
 Event flags allow simple implementation of the barrier
synchronisation problem in two different ways
 Mutex variable & one event flag
 Multiple event flags
 The disadvantage of using event flags for synchronisation is that
their value must be reset before they are reused for another
synchronisation operation
 This is different from semaphores which "auto-reset" on waking a task

Solution 2: Mutex Variable & Event Flag
 The first semaphore can be void Barrier()

eliminated if we use a small critical {
section of code /* Barrier pojnt A */
ENTER_CRITICAL_SECTION();
 of course, this could be implemented
using a semaphore to enforce mutual Synch = Synch+1;
exclusion if (synch == NSYNCH) {
EventFlagChange(FlagsB,1,1);
 The function Barrier() below is
}
called by all tasks to synchronise
EXIT_CRITICAL_SECTION();
when they reach the barrier. It
EventFlagWaitAll(FlagsB,1,1);
performs all the necessary
/* Barrier point B */
synchronisation.
}
 FlagsB must be created before this
code is executed void BarrierInit()
 BarrierInit() resets everything for the {
next synch.
Synch=0;
 Not easy to ensure all tasks are EventFlagChange(FlagsB,1,0);
waiting before BarrierInit() is called
}

Solution 3: Multiple event flags
 Each task to be synchronised sets one event flag on

reaching the barrier & then waits on all flags set
Select
Flag n Set
Task( int n)
{ Flag
/* barrier point A */
EventFlagChange(FlagsB, (1<<n), 0xFF); Wait on all
EventFlagWaitAll(FlagsB,0xFF, 0xFF); flags 7..0 set
/* still not easy to ensure that all tasks are waiting
before flags are reset */
}
/*Assume 8 tasks created with n = 7..0*/

Solution 4: Multiple event flags
Can avoid reset by using differential change in flag state.

Invert value of flag each time barrier is crossed.
Must keep track of old flag values in variable, or read it via API
function.
Task( int n)
{
char flagValue=0x00; /* either 0x00 or 0xFF */
for (;;) {
/* barrier point A */
flagValue = flagValue ^ 0xFF; /* invert value of flag
EventFlagChange(FlagsB, (1<<n), flagValue); /*mark this task at A*/
EventFlagWaitAll(FlagsB,0xFF, flagValue);/*wait till all tasks at A*/
}
}
/*Assume 8 tasks created with n = 7..0*/

Lecture 6 Summary
 Barrier synchronisation is often necessary when

multiple tasks cooperate on solution of a problem
 Can be solved using semaphores
 May need to use counting semaphores
 Better solutions use event flags
 One flag and a mutex variable
 One flag per task to be synchronised
 Event flag registers allow waiting on arbitrary AND or
OR of boolean condition variables "flags"
 Event flags are important because there are many
synchronisation problems which cannot easily be
solved by semaphores.

Lecture 7: Scheduling Theory
Deadlines are things that we pass through on

the way to finishing.
Peter Gabriel
 In RTOS applications tasks have deadlines. This

lecture will look at what these are, and how design can
ensure that they are met.
 This lecture has two parts
 1. How are tasks scheduled?
 2. Deadline guarantees through Rate Monotonic Analysis

Scheduling
 At any time during execution of an RTOS there is a set of READY

tasks.
 Only one task can be running at a given time
 The scheduler must decide which of the READY tasks runs
 In implementations, there are two separate decisions to be made
about scheduling:
 When does scheduling happen (with possible switch in running task)?
 Which task is selected to run?
 Most RTOS have a scheduler internal function which is called
whenever scheduling is allowed to happen and which selects the
next task to run and (if it is not already running) performs a task
switch
 We look at the mechanics of the task switch in Part 2

When to schedule?
 All RTOS must schedule when the current running task calls a
blocking API function.
 Otherwise the system would halt!
 Other than this, we will examine three commonly used choices for
when to schedule:
 Non-preemptive (coroutine) scheduling
 All scheduling is explicitly allowed by the running task
 At other times preemption is not allowed
 Preemptive scheduling
 The RTOS scheduler is called whenever something happens which may
change the scheduling decision:
 Task priority changing
 Task changing state
 Preemptive scheduling with time-slicing
 The scheduler is called from system clock tick even when no task has
changed state

Co-routine scheduling
 Co-routines are tasks which must co-operate in their own scheduling.

 An API function TaskYield() allows any task to call the scheduler
 Will either return with no operation or if another task needs to run will result in task
switch
 Blocking API functions call the scheduler when they block
 Otherwise scheduling cannot happen
 Advantages
 Scheduling is always via function call. Although separate stacks are still
needed and context must be saved on stck, but there is less context to save.
 The task-switch looks to the compiler like a function call/return. Registers which
the compiler expects to be changed by a function call therefore do not need to be
saved
 Less context to save  faster context switch, smaller stacks
 Critical sections are no longer necessary! No code can be interrupted by
another task unless it explicitly calls the scheduler or a blocking API function.
 This makes code more efficient, and easier to write.
 RTOS Kernel scheduling code is usually simpler

Co-routine scheduling (cont'd)
 The advantages on the previous slide mean that co-routine based systems
are very compact and efficient.
 There are however big disadvantages which mean that most RTOS (and
nearly all large RTOS) use preemptive scheduling.
 Disadvantages
 All application code must be written correctly – TaskYield() must be called
within any loop that may last a long time.
 A single "rogue" task will freeze the entire system
 It is possible (but complex) to require compilers automatically to insert TaskYield()
within every loop.
 Task-level response time is not easily guaranteed, since it depends on
maximum length of time between TaskYield() calls.
 Calls to TaskYield() in inner loops can slow down execution
 Note that co-routines and tasks can co-exist within one system – so
getting the advantages of both at the cost of some complexity
 FreeRTOS allows mixed co-routines and tasks
 Co-routines run within a single task

Preemptive scheduling
 Preemption means task switches as the result of an interrupt

 From hardware device interrupt, where the ISR signals an OS object
and unblocks a task
 From timer interrupt which drives the system clock tick and may wake
up tasks waiting on delay.
 The implementation cost is that task switch must be implemented
both from a task (blocking API function) and direct from interrupt.
 Since all state must sometimes be saved, all state must always be
saved to make task switch uniform.
 Task-level task switch is usually implemented using a software
interrupt followed by the same mechanism as for interrupt-level
switch
 Advantage: can ensure that at all times the highest priority task
which is READY will be running.

Time-slice (round-robin) Scheduling
 This is a small addition to preemptive deadline
scheduling. Sometimes it is useful to Task1
have tasks which share execution time.
This can be implemented in a time- Task2
slicing system by giving tasks the same Priority scheduling
priority. The scheduler will allocate to
each task a time-slice before switching finish
to the next task.
 Surprisingly, this feature is not usually
what is needed in a real-time system. Task1
Given two tasks of equal priority (same Task2
deadline):
 All that matters is do they both meet the Time-slice scheduling
deadline
 This is no more likely if they time-slice
Time-slice scheduling
 In fact slightly less likely since the
switching consumes CPU time is fairer but overall
 If one task finishes first it will release worse for finish times
system resources which may help other
tasks.

Which task to schedule?
 Nearly all RTOS use priority-based scheduling. This allows tasks

with tight deadlines to run faster, as is usually required.
 Assign to each Task i a priority Pi
 Scheduler (called whenever task blocks or unblocks):
 If the current RUNNING task is READY and has highest priority make no
change
 Otherwise schedule the READY task with highest priority
 In an RTOS no task (except for the lowest priority task) should run
with 100% CPU utilisation, since this will block lower priority tasks
 In an RTOS tasks unblock in response to some event, implement
some real-time operation, and then block again
 Priority scheduling works well

Deadlines
 Real-time systems are classified according to what happens if

deadlines are missed
 Hard Real-time
 Missing deadlines is disastrous
 E.g. aeroplane crashes
 Hardware failure
 Nuclear power plants (!)
 Soft Real-time
 Missing deadlines degrades performance & is undesirable, but not
catastrophic as long as infrequent
 DSP systems for real-time voice processing
 Airline real-time booking processing systems
 Either way, real-time systems have deadlines
 Contrast this with application tasks on a PC where there is no fixed
completion deadline, though speed is also desirable.

Job model for tasks in an RTOS
Fixed time between
events: Ti
Task running Task running
Deadline =
Fixed CPU
Next event
execution time: Ci
 Assume tasks wait on a periodic event

and then have a fixed amount of CPU Task()
time to use before they block on the {
next event for ( ; ; ) {
 For correct operation the work [ wait on next event ]
associated with an event must be [ process event ]
complete before the next happens
}
 Good model for many RTOS tasks
}
 Ignores task synchronisation &
resource access blocking
 Allows analysis of different scheduling
strategies

Earliest Deadline First (EDF) Scheduling
 Fixed Priority scheduling is not optimal for meeting deadlines.
 If deadlines are known in advance then in principle EDF scheduling
will meet deadlines if any scheduling strategy can do this.
 At any time schedule the READY task whose deadline will happen first
 Not difficult to prove that this is optimal (if tasks block once per deadline)
 In practice not often used
 Very time-consuming to implement as number of tasks increases
 Difficult to get information on when future deadlines will happen
Task 1 runs because
of earlier deadline
READY Deadline
Task 1
Task 2
Task Task
Task 2 runs because
ready running
of earlier deadline
Round-robin scheduling
 Feature can be added to priority scheduling.
 Allow tasks to have equal priority.
 Run set of equal priority tasks in equal time-slices and strict rotation
 When a task blocks before the end of its time-slice start the next one early
 As pointed out earlier this strategy is not usually good for RTOS where
early completion is more important than fairness.
 Round-robin scheduling simple. It has the merit that READY tasks are
guaranteed to be given a time-slice within a given time.
blocked
Why is it not good to
switch round-robin to
Task1 a new task every
Task2 time-slice?
Task3

Rate Monotonic Analysis
 Suppose all N tasks in an RTOS follow the job model (slide 1.123)
 Task i executes with CPU time  Ci
 Task i waits on event with period  Ti
 Task i has no other blocking (ignore synchronisation with other tasks)
 Schedule task i with fixed priority Pi so that faster deadlines have
higher priority
 Ti < Tj  Pi > Pj
 Then the system is guaranteed to meet all deadlines providing the
total CPU Utilisation U is less than the RMA limit for N tasks U(N)
 U =  Ui =  (Ci/Ti) < U(N) = N(21/N-1)
 Note that variable times are allowed as long as they obey the given
inequalities

Example
 Consider 3 tasks as in the table
 The priorities must be assigned as shown, inversely with period.
 The total CPU utilisation U is 0.767
 The RMA limit is
U(3) = 3(21/3-1) = 0.780
 Therefore the system meets the RMA limit and is guaranteed to
meet all deadlines.
Task T C U Priority
1 30ms 5ms 0.167 3
2 10ms 3ms 0.333 1
3 15ms 4ms 0.267 2

RMA discussion
 Rate Monotonic Analysis provides a guarantee that systems

obeying the RMA conditions WILL always meet deadlines.
 It does not say that systems with higher utilisation will NOT meet
deadlines.
 It is seldom possible to apply it exactly because most systems do
have some inter-task synchronisation which slows down tasks
 In practice, it is a good guide as to what is a reasonable system
 The RMA utilisation limit U(N) decreases monotonically with
increasing N and has asymptotic value of loge2 = 0.693
 As a rule of thumb RTOS with many tasks should never run with
utlisation higher than this limit.
 For safety, most realisable designs should run well below the RMA
limit
 If the RMA limit is not met, for a given application, the solution is
either to use a faster CPU, or, possibly, reduce the number of
tasks.

Extended RMA
 We can include the effect of tasks blocking due to inter-task mutual-
exclusion etc.
 Suppose the maximum time Task i can block before it completes is Bi
 Replace Ci by (Ci+Bi) in the RMA limit calculation
 ((Ci+Bi) /Ti) < U(N) = N(21/N-1)
 NB - blocking is not the same as waiting to run at a lower priority, which is
included in RMA limit. Therefore Bi is the sum of all blocking on lower priority
taks, and blocking on higher priority tasks only when they are themselves
blocked.
 This can be helpful where an upper bound can be put on blocking through
mutual exclusion
 Where no such upper bound exists the system is unsafe and should not
be used!

Estimating blocking Bi
 Suppose Task i blocks due to access to a shared resource governed by
semaphore S, and has no other blocking while it executes. Assume
 During each computation Ci the task i claims S at most once.
 The maximum time (critical section length) for which any task j claims S is Kj.
 NB we do not consider priority inversion here – which can increase this maximum time to longer
than expected – see Lecture 9
 No task can claim S more than once while a given task is waiting
 Worst case, when waiting on semaphore S, Task i may have to block while one
task of lower priority claims the semaphore: Bi  max( K j | j  i)
 Tasks of higher priority claiming semaphore do not count as blocking, since they
would run anyway and having claimed semaphore cannot block
W2 = K1+K4+K3 Blocked on S Acquired S

4
3
Task
2
1
Further reading on scheduling
 A good accessible overview of hard real-time scheduling issues

and deadline-based methods of scheduling from Peter Dibble
 http://www.embedded.com/showArticle.jhtml?articleID=9900112

Lecture 7: Summary
 Scheduling can be through co-routines, or preemptive

 Co-routines task-switch faster, and have some programming
advantages, but suffer from unpredictable and longer task response
time.
 Scheduling can be priority-based, or (much more complex) using
EDF
 EDF meets deadlines better but is usually too difficult to implement
since deadlines cannot be easily be precisely determined in advance.
 Round-robin scheduling allocates time fairly to tasks of equal
priority
 Provides fairness at the expense of quicker completion
 Priority-based scheduling can be analysed for a job model of
tasks using Rate Monotonic Analysis (RMA) which subject to
certain conditions guarantees all deadlines will be met if the CPU
uttlisation U is less than the RMA limit U(N).

Lectures 8 & 9: Liveness Problems in Real-
Time Systems
Never discourage anyone...who continually makes progress, no
matter how slow.
Plato
If debugging is the art of removing bugs, then programming
must be the art of inserting them.
Unknown
 Real-time systems must have correct timing, with all deadlines

met, as well as correct function.
 Rate Monotonic Analysis only guarantees timing when tasks do not
block, or have limited time blocking
 This lecture looks at scheduling problems which can cause tasks to
block indefinitely or for much longer than expected
 Collectively these are called liveness problems
 We will consider
 How to predict and avoid problems
 How to correct problems
Anatomy of problems
 We will look at four common types of problem which

mean tasks make no or slow progress:
 Deadlock
 Starvation
 Livelock
 Priority Inversion
 All have the characteristic that they are scheduling-
dependent.
 Given different a different scheduler they need not happen.
 Contrast this with CPU utilisation > 100% which is a problem
that cannot be cured by ANY schedule.
 RMA does not help with these problems
 RMA asumes tasks do not block waiting on resources

Deadlock
 A set of tasks D is deadlocked if

 All tasks in D are blocked indefinitely
 Regardless of future scheduling all tasks in D will stay blocked
 No way out of deadlock
 If the set of tasks is the whole system no further computation can be
done.
 Deadlock is a global property of a system (or part of a system) it
cannot easily be detected and avoided at a task level.
 Deadlock can occur very easily
 programmers who do not consider it will almost certainly find that any
medium-sized system deadlocks.
 Therefore understanding it and avoiding it through analysis is essential
 Global mechanisms to detect and recover from deadlock exist,
however it is usually essential to avoid deadlock in the first place

A simple example
T1()
 Consider two tasks T1 & T2 which are
part of a concurrent system and shared {
resources A and B. The resources could
be shared memory, hardware, etc. A1: [ acquire Sa ]
 Each resource is protected by a B1: [ acquire Sb ]
semaphore (Sa and Sb) C1: [ perform computation using A and B ]
 To perform part of the computation each D1: [ release Sb ]
task needs to use both A and B. E1: [ release Sa ]
 Can you see what is wrong with the }
code?
 Mutual exclusive use of A & B is T2()
guaranteed
{
 Each task claims and then releases each
semaphore once, as it should. A2: [ acquire Sb ]
 The two tasks can deadlock! B2: [ acquire Sa ]
 A1,A2,B2( T2 blocks on Sa),B1(T1 blocks C2: [ perform computation using A and B ]
on Sb)…… D2: [ release Sa ]
E2: [ release Sb ]
}

Discussion
 This example reveals some interesting
features of deadlock wants
 Attaining the deadlocked state A T2
depends on scheduling.
 In this case one of the tasks must acquire holds
its first semaphore during the (short) time
between when the second task acqires its holds
first & second semaphore
T1 wants
 The deadlock, once achieved, is non- B
recoverable.
 We will consider later more complex
systems which do allow recovery,
providing the resource is preemptible. Resource graph
 The deadlock is caused by a cyclic illustrates cyclic
dependence between tasks, each of dependence
which wants a resource held by
another task
 Cycle can include N tasks & N resources
(N2)

The Classic problem
 Deadlock can involve any

number of tasks. The classic
example is the so-called
Philosopher's Dining Problem.
 Philosophers eat at a circular
table
 Each Philosopher needs two
forks to eat
 The table is laid with each fork
shared between two philosophers
 Incorrect scheduling will lead to
all philosophers having picked up
one fork, waiting on the other
one.

Conditions for Deadlock
 Non-preemptability
 Resource once allocated can't be released until task has finished.
 Don't confuse this with task preemption
 Exclusion
 Resource can't be held simultaneously by two tasks
 Hold-and-Wait
 Holder blocks awaiting the next resource
 Circular waiting
 tasks acquire resources in different orders

Strategies
 Deadlock is a key problem in concurrent system design. There are

three types of strategy to deal with it:
 Deadlock detection & recovery
 Deadlock avoidance
 Deadlock prevention
 One or other of these is essential for correct operation of any
complex concurrent system

Deadlock Detection & Recovery
 A stable deadlock (as on previous slide) is where none of the

deadlocked tasks expect a timeout or abort to break the deadlock
 Deadlock detection is a global algorithm used by the RTOS to
detect deadlock situations and recover – externally from the tasks
which are deadlocked.
 Can be useful as a debugging aid, but in practice recovering from
deadlock is difficult
 Temporal deadlock is a situation where one or more of the
deadlocked tasks time out or aborts, thus freeing the requested
resource and eliminating the deadlock.
 Here the recovery mechanism is local to a single task
 Recovery from deadlock requires a reversal of previous resource
allocation
 Either preempt the resource, if this is possible without disturbing task
execution
 Or roll back the task to a checkpoint before the resource was
allocated, and free the resource.

Deadlock Avoidance
 Deadlock requires a cyclic resource graph. The RTOS can track

resource dependence and detect when a resource allocation
request will lead to a cycle. The wait operation can then return with
an error indication.
 This is like global detection except that errors are discovered earlier
and therefore recovery is easier.
 Detecting cycles in the resource graph is however resource-intensive
and requires a graph analysis algorithm to run every time a resource is
requested or released.

Deadlock Prevention
 Best technique for small to medium-sized
systems.
 Simple & robust T1 T2
 No run-time cost A,B,D C,B
 Disadvantage: relies on conservative
resource use so may make systems
slower than is possible.
 Establish a global allocation order on
resources such that when resources A,B
are used at the same time by a given T3 T4
task, either A<B or B<A. E,F A,F
 Constrain all tasks so that resources are
acquired (SemaphoreTake() etc)
according to this order.
 It does not matter in what order resources
are released.


Using Timeouts
 There are cases where some known error condition (other than
deadlock) can be detected using a timeout.
 In this case the timeout is part of normal operation
 More often long delays in obtaining a resource are not expected
 A timeout indicates an error condition
 Defensive programming
 Use long timeouts – should never happen
 Stop system with error on timeout.
 Don't rely on this to detect deadlock conditions
 Deadlock may be possible but never happen due to scheduling
 Such a system is unsafe and may deadlock in the future as the result
of any small change
 Make sure deadlock is prevented by design, as on previous slide.

Starvation
 Symptoms
 One (or more) tasks wait indefinitely on a shared resource held
by other, normally running, tasks.
 Cause
 Two or more other tasks are using the resource in turn, without
break, denying the starved task usage.
 Total resource utilisation (analogous to CPU utilisation) is
100%
 If higher priority tasks have 100% CPU utilisation so preventing
execution of lower priority task this is special case of starvation.
 Starvation depends in general on details of scheduling,
it is trickier to diagnose than deadlock
 In starvation, a task is prevented from execution by
other tasks, which themselves are executing normally

Starving Philosophers
 To illustrate starvation consider a variant Philosopher()

of the 3 Philosopher's problem {
 Philosophers "big Ned" & "big Tony" have [ pick up ladle ]
priority over "Tiny Tim" [ wait 30 seconds (eating) ]
 Philosophers share a single ladle [ replace ladle ]
 ladle = semaphore-protected resource [ wait 29 seconds (talking) ]
 Each philosopher spends a fixed time }
eating with the ladle, and then releases
the ladle for another fixed time, during
which they talk.
Big Big
 Two philosophers eat while the other is
Ned Tony
literally starved
 Note that the ladle is 100% utilised. If
the talking time were increased to 31s it
would be free for Tim 1s every half minute
and all Philosophers would be able to
share it.
Tiny
Tim
Deadlock vs Starvation
 Deadlock and starvation are easily confused.

 One way to see the difference is that although both start in a way
that is dependent on the task scheduling, once they have started:
 Deadlock can't be broken by any task schedule (because of the cyclic
resource dependence)
 Starvation can be broken by a fairer task schedule (making the tasks
that are hogging the resource execute less)
 Fixed priority scheduling, used in RTOS, tend to be unfair & can thus
generate starvation easily
 The previous slide example is typical of starvation – a task waits on
a resource which is used alternately by a number of higher priority
tasks, and therefore never available.

Livelock - a system designer's nightmare
 The problem in livelock is that although all tasks are

seemingly executing normally (ie not suspended
indefinitely) no progress is made.
 The best analogy is two people wanting to pass in a passage,
who by bad luck each move to the right and left at the same
time, so neither can pass.
 In principle (and in concurrent systems) this can continue
indefinitely.
 There are two variants of livelock, explained on the next
slides.
 Pseudo-deadlock
 Real livelock

Pseudo-Livelock
 For example, Dining Philosophers are all doing "pickup left fork;
busy/wait loop until right fork is free" and pick up left forks at
same time.
 This is really a hidden form of the classic deadlock - the busy/wait
polling loops make it seem that something is happening, when really
the tasks are all waiting on resources.
 In this case, as in deadlock, the pseudo-livelock can't be broken by
any scheduling order.
 More interestingly, livelock may be dependent on scheduling, so
that even after it occurs it could be broken by a different execution
order.
 See next slide

Real Livelock
 Consider the deadlocked philosophers with deadlock

broken by a fixed timeout.
 This is NOT a deadlocked system, since the shared resources
are released after the timeout allowing the system to progress.
 Suppose that all pick up the first fork simultaneously,
and all wait on the second fork at the same time. All will
then timeout at the same time, and try again.
 The cycle will repeat indefinitely!
 Solution here is to add to each task a different back-off time
 Task is unable to retry until back-off time expires
 Typically use pseudo-random numbers to determine back-off time
 Ethernet protocol does exactly this to prevent livelock
on ethernet networks due to repeated network collisions

Priority Inversion
 A high priority task DiskDriver() shares a resource with a low priority task KbdManager()
using a semaphore S.
 Assume no other READY tasks in the system
 The resource is locked for a short time T by either task
 When using S DiskDriver() must wait worst case for up to T while Keyboardmanager() finishes
using S (priority inversion).
 Now suppose there is another task in the system Task2() which has priority just greater
than KbdManager(). This can preempt KbdManager() while it holds S
 Effectively DiskDriver() is reduced to the priority of KbdManager() because Task2() runs
in preference to it.
 The period of priority inversion is now determined by Task2() & effectively unbounded.
Priority inversion
Running
DiskDriver()
Ready
Task2() Blocked
Waiting S
Kbdmanager() Holds S

Priority Inheritance Protocol (PIP)
 The solutions to this problem all use dynamic priorities. The idea is that
KbdManager() should have its priority temporarily increased.
 Priority Inheritance Protocol (PIP)
 Any task T which claims the semaphore S has priority dynamically increased to
that of the highest priority task waiting on S
 We say it inherits priority of this task.
 Priority is increased to ensure this whenever a higher priority task waits on S
 When T releases S it will drop back to its old priority
 Priority inheritance is transitive.
 In PIP, a task can be blocked by a lower priority task in two ways
 Direct blocking – when LPT has resourced needed by task
 Push-through blocking - when task is prevented from executing due to LPT
having inherited priority higher than task we call this
 PIP limits max blocking to at most one critical section for each semaphore,
and also at most one critical section for each lower priority task
 Schedulability (RMA etc) is determined by total blocking

Ceiling Priority Protocol (CPP)
 An different protocol keeps track for every resource R of the

highest (static, not inherited) priority task that could use R – this is
the static ceiling priority of the resource. The idea is then to give
any task holding R its ceiling priority, whether or not any other task
is waiting
 This speeds up critical sections of code and gets them out of the
way more quickly.
 When compared with PIP it can therefore reduce average blocking
in higher priority tasks, although it cannot reduce worst-case
blocking

Priority Ceiling Protocol (PCP)
 Combines PIP with CPP

 The idea is to add some extra cases to where blocking occurs to PIP in
order to reduce the overall time a task can be blocked by a lower priority
task.
 This is a dynamic priority protocol which avoids priority inversion and also
avoids deadlock.
 The ceiling priority for each resource is calculated as on the previous
slide
 The current priority ceiling for a running system is defined to be the
highest ceiling priority of any resource currently locked (i.e. with
semaphore token given to a task).
 Note that different tasks may hold each resource
 When a task T requests a resource R the PCP protocol states:
1. If R is in use, T is blocked
2. If R is free and the priority of T is higher than the current priority ceiling, R is
allocated to T
3. If the current priority ceiling is attained by one of the resources T currently
holds, R is allocated to T, otherwise T is blocked.
4. When T is blocked, the running task inherits T's priority if higher and executes
at this priority until it releases every resource whose ceiling priority is higher
than or equal to T's priority. The task then returns to to its previous priority.

PCP example
 Task1 & Task2 have priority 1 & 2 Task1()

respectively. {
 Both use resources A & B [ claim A ]
 They request these in opposite [claim B ]
order so as to make a classic
dining philosopher's deadlock
[release A]
possible [release B]
 Ceiling priority of A & B is 2. }
 Whichever Task first claims
either A or B will raise current Task2()
ceiling priority to 2. {
 The other task is therefore [ claim B]
unable to claim A or B [claim A]
 The task which has claimed A or [release B]
B will therefore always be able to
claim the other resource [release A]
 When both resources are }
released the current priority
drops to 0 and then either
resource may be claimed again.

PCP Analysis
 Under PCP, a task T can be blocked by a lower priority task for 3

different reasons:
 Direct blocking - T is blocked because some other running task
currently has the resource
 This is unavoidable because of mutual exclusive access
 Push-through blocking - T can be blocked when the blocking task has
inherited a higher priority than T
 Similar to what would happen under a priority inheritance protocol
 This is necessary to prevent unbounded priority inversion
 Priority ceiling blocking – if the priority ceiling of all resources currently
locked by tasks other than T is higher than or equal to the priority of T,
then T is blocked.
 This prevents deadlock as proved in the next slide.

Blocking under PCP
 The total system blocking under

PCP is more than under PIP,
because of the extra condition
(priority ceiling blocking) that can
block tasks.
 However the maximum time a task
can be blocked by lower priority task
is now much less, and at most one
critical section
 Also deadlock is impossible
 This is the critical property that
enables rate monotonic analysis to
be done proving that all tasks will
meet deadlines
 The maximum blocking time for any
task is now optimally bounded.

What Really happened to Pathfinder on
Mars?
 A fascinating historical bug caused by priority inversion

 Bug caused catastrophic Pathfinder systems resets
 Bug first ocurred on Mars!
 Diagnosed on Earth after careful simulation
 Cured by bug fix uploaded from Earth
 Documents:
 Informal account of the problem
http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.
html
 And authoritative follow-up from Glen Reeves of JPL, who led the
team finding the bug

Lectures 8 & 9: Summary
 Concurrent systems can suffer from:

 Deadlock
 Starvation
 Livelock – pseudo-livelock or real livelock
 Priority inversion
 Deadlock can be analysed by considering the resource
dependency graph and dealt with through:
 Detection & recovery
 Avoidance
 Prevention
 Protocols exist to stop priority inversion using dynamic task
priorities:
 Priority Inheritance Protocol
 Ceiling Priority Protocol
 Priority Ceiling Protocol (eliminates deadlock as well)

Real-Time Operating Systems: Part 1: Mars Pathfinder 1997

Uploaded by

Copyright:

Available Formats

Real-Time Operating Systems: Part 1: Mars Pathfinder 1997

Uploaded by

Document Information

Original Title

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

Real-Time Operating Systems: Part 1: Mars Pathfinder 1997

Uploaded by

Copyright:

Available Formats

Real-Time Operating Systems: Part 1

Industrial robot 2006

Design & Analysis for Embedded & Time-Critical Systems

tjwc - 10-Feb-09 Real-Time Operating Systems 1.1

tjwc - 10-Feb-09 Real-Time Operating Systems 1.2

1.1 Introduction PART 1 PART 2

tjwc - 10-Feb-09 Real-Time Operating Systems 1.3

 Use LPC2138 microprocessor & Keil development tools

tjwc - 10-Feb-09 Real-Time Operating Systems 1.4

tjwc - 10-Feb-09 Real-Time Operating Systems 1.5

tjwc - 10-Feb-09 Real-Time Operating Systems 1.6

tjwc - 10-Feb-09 Real-Time Operating Systems 1.7

 RTOS – Real-Time Operating System

tjwc - 10-Feb-09 Real-Time Operating Systems 1.8

 What is a Real-Time Operating  Basic framework

tjwc - 10-Feb-09 Real-Time Operating Systems 1.9

 Normally a single CPU runs multiple programs (called tasks).

State Sub-state description

Running Only one task can be running at one time

 How are tasks scheduled (when does execution need to switch)?

tjwc - 10-Feb-09 Real-Time Operating Systems 1.12

tjwc - 10-Feb-09 Real-Time Operating Systems 1.13

void vKeyHandlerTask( void *pvParameters )

tjwc - 10-Feb-09 Real-Time Operating Systems 1.14

 To make this system more complex, suppose there is another task

tjwc - 10-Feb-09 Real-Time Operating Systems 1.15

tjwc - 10-Feb-09 Real-Time Operating Systems 1.16

tjwc - 10-Feb-09 Real-Time Operating Systems 1.17

tjwc - 10-Feb-09 Real-Time Operating Systems 1.18

tjwc - 10-Feb-09 Real-Time Operating Systems 1.19

tjwc - 10-Feb-09 Real-Time Operating Systems 1.20

Implementation Choose & write write

FreeRTOS for coursework Next Lectures

tjwc - 10-Feb-09 Real-Time Operating Systems 1.21

 Real-time computation can be implemented via multitasking where

tjwc - 10-Feb-09 Real-Time Operating Systems 1.25

 FreeRTOS is a simple Gnu Public License (GPL) real-time OS written in C which

tjwc - 10-Feb-09 Real-Time Operating Systems 1.26

 In FreeRTOS a task is  All FreeRTOS tasks are created

tjwc - 10-Feb-09 Real-Time Operating Systems 1.27

Constants in C use /* constants */

void vLcdDriveTask(void *pvParameters)

vlcdStartLcdTask( mainLCD_TASK_PRIORITY); Task creation details have been put

vTaskStartScheduler(); After scheduler starts it will normally

 FreeRTOS stack sizes are measured in number of stack items

tjwc - 10-Feb-09 Real-Time Operating Systems 1.32

 Task creation uses RAM

tjwc - 10-Feb-09 Real-Time Operating Systems 1.34

Task is ready, but not scheduled due to a higher priority task

tjwc - 10-Feb-09 Real-Time Operating Systems 1.36

/* Perform an action every 2 ticks. */

tjwc - 10-Feb-09 Real-Time Operating Systems 1.37

 2. Disable scheduling (preemption-lock)

tjwc - 10-Feb-09 Real-Time Operating Systems 1.38

 In real-time system assume normal state for all tasks is blocked!

tjwc - 10-Feb-09 Real-Time Operating Systems 1.41

tjwc - 10-Feb-09 Real-Time Operating Systems 1.42

 A serial port driver task runs code of the form:

tjwc - 10-Feb-09 Real-Time Operating Systems 1.43