1. Complexities Arising in Real Systems
In the task model assumed so far,
all tasks are independent,
there is no penalty for preemption,
preemptions may occur at any time, and
an unlimited number of priority levels exists.
What do we do for cases where these assumption do not hold?

2. Effect of Blocking on Schedulability
Tasks may have nonpreemptive regions due to system calls,
critical sections, I/O calls, etc.
Suppose we know that bi is maximum total duration for which each
job of task Ti may be blocked by lower-priority tasks.
How does the scheduling analysis presented previously change?
Fixed-Priority Systems
Time-demand analysis. Similar to before, but the TD function is now:

3. Schedulability Under EDF
Theorem: In a system where jobs are scheduled under EDF,
a job Jk with relative deadline Dk can block a job Ji with relative
deadline Di if and only if Dk > Di.
In an EDF-scheduled system, all deadlines will be met if the following
holds for every i = 1, 2, …, n:
The theorem basically shows that “priority” in EDF world is determined by deadline. A lower priority task is a task with later deadline.

4. Effect of Suspensions
Example Schedule: Three tasks, T1 = (3,0.5), T2 = (4,1), T3 = (6,2).
Here’s the system with no suspensions: T1 T2
What causes suspensions? For example, let’s say a task needs to send a few internet packets and then wait for a response from an external device. What does it do while waiting? Either spins in a while loop, checking constantly T3

5. Effect of Suspensions
Example Schedule: Three tasks, T1 = (3,0.5), T2 = (4,1), T3 = (6,2).
Here’s the system assuming J2,2 begins with a 2 time unit suspension: T1 T2 T3
T1 is completely unaffected by T2’s suspension.
T3’s worst-case response time lengthens from 4 to 5 time units.

6. Scheduling Analysis with Suspensions
Calculate a “blocking term” due to suspensions:
We are adding the effects of self-suspension plus potential delay of higher priority task suspensions to the blocking term
bi(ss) = maximum self-suspension time of Ti
+ k=1,…,i-1 min(ek, maximum self-suspension time of Tk)
fixed-priorities assumed here

7. Context Switches In reality, context switches don’t take 0 time.
In a preemptive system in which job priorities are fixed (e.g., RM, DM, or EDF) we can inflate job execution costs as follows.
If each job of Ti self-suspends Ki times, add 2(Ki + 1)CS to ei.
In a scheme like LLF, in which a job’s priority is dynamic, context switching costs may be prohibitive.
A nonpreemptive scheme will context switch the least.
Proofs that EDF is better than nonpreemptive EDF assume a cost of zero for preemptions!

8. Limited Priority Levels
In reality, the number of priority levels in a system will be limited.
Most real-time OSs have at most 256 priority levels.
As a consequence of this, we may have multiple tasks per priority level. Two issues:
How does this impact scheduling analysis?
How do we assign real priorities?

9. Scheduling Analysis
Most systems schedule same-priority tasks on a round robin or FIFO
basis. Assuming this, we can adjust our analysis as follows.
TDA: The time-demand function becomes:
We sum up the execution times of all tasks at same priority level (in a FIFO with RM-based priority, up to and at most one job from each other same priority task can execute before a given task) Th is the set of tasks who’s priority is higher than Ti.

10. Tick Scheduling
We have assumed so far that the scheduler is activated whenever a job is released.
In many systems, the scheduler is activated only at clock interrupts.
This is called tick scheduling, time-based scheduling, or quantum-based scheduling.
Two main consequences for scheduling:
We must regard the scheduler itself as a high-priority periodic task.
We may have additional blocking times due to the possibility that a job can be released between clock interrupts.

11. Caches and Virtual Memory
Caches are problematic for (at least) three reasons:
Conditional branches make it difficult to predict which instructions and data will be needed next.
Generally, it is harder to predict whether a data item will be in the cache than whether an instruction will be in the cache.
Preemptions and migrations can cause blocks brought into the cache to be removed.
With shared caches on multicore platforms, it seems impossible to predict what’s happening on other cores.
Both an issue for timing analysis and overhead analysis.

12. Mixing Real-Time and Non-Real-Time in Priority-Driven Systems

13. Sporadic and Aperiodic Tasks/Job
Sporadic task: Ti is specified by (i, pi, ei, Di).
pi is the minimum time between job releases.
Aperiodic jobs: non-real-time.
Released at arbitrary times.
Has no deadline and ei is unspecified.
How do we meet the following goals?
Never miss the deadline of a sporadic task
Minimize either the response time of the aperiodic job at the head of the queue, or the average response time of all aperiodic jobs.
The first goal produces a correct scheduling algorithm. The second produces

14. Background Scheduling
Sporadic tasks are scheduled using any priority-driven scheduling algorithm.
Aperiodic jobs are scheduled in the background:
Aperiodic jobs are executed only when there is no sporadic job ready to execute.
Simple to implement and always produces correct schedules.
The lowest-priority task executes jobs from the aperiodic job queue.
We can improve response times without jeopardizing deadlines by using a slack stealing algorithm to delay the execution of sporadic jobs as long as possible.

15. Server Scheduling
Sporadic tasks are scheduled using any priority-driven scheduling algorithm.
Aperiodic jobs are executed by a special server:
The server is given an execution budget es.
Server jobs consume the budget as they execute
No server job can execute when the budget is depleted
Budget is regularly replenished according to an algorithm dependent on the type of server

16. Example: Deferrable Server (DS)
Let the task TDS = (ps, es) be a deferrable server.
Replenishment Rule:
The execution budget is set to es at time instants kps, for k0.
Note: Unused execution budget cannot be carried over to the next period.
The scheduler treats the deferrable server as a sporadic task that may suspend itself during execution (i.e., when the aperiodic queue is empty).
This is a simple type of “bandwidth-preserving” server, i.e. a server that maintains budget even after it has finished executing all pending server tasks.

17. DS with RM Scheduling
Another Example: Two tasks, T1 = (2,3.5,1.5), T2 = (6.5,0.5), and a deferrable server TDS = (3,1). Assume an aperiodic job Ja arrives at time t = 2.8 with and execution time of ea = 1.7.
The response time of the aperiodic job Ja is 3.7.
1.0
TDS Budget
TDS
2.8
6.5 T1
4.7 T2
Comp 737, Fall 2014

18. Double-Hit Example TDS Budget TDS t0 T1 T2 t0=
1.0
TDS Budget
TDS t0 T1
T1 just makes it! T2
t0=
Notice that the processor demand created by the DS in the interval [65, completion of T1’s job] is twice what it would be if it were an ordinary sporadic task! This is because we preserve the bandwidth of the DS.

19. TDA with a DS Observation:
Initial es: Demand of the server if it consumes budget at the beginning the time demand interval, but at the end of its period.
Next es term: demand the DS can produce with remaining time t-es in the interval
This fully encompasses the double-hit demand of the server
Assumes

20. Total Bandwidth Server (TBS)
One way to reduce the response time of aperiodic jobs whose wcet is known in a deadline-driven system is to
allocate a fixed (maximum) percentage, US, of the processor to serve aperiodic jobs, and
make sure the aperiodic load never exceeds this maximum utilization value.
When an aperiodic job comes in, assign it a deadline such that the demand created by all of the aperiodic jobs in any feasible interval never exceeds the maximum utilization US allocated to aperiodic jobs.

21. Schedulability with a TBS
A necessary and sufficient schedulability condition for TBS under implicit deadline systems
Theorem: A system T of n independent, preemptable, sporadic tasks with relative deadlines equal to their periods is schedulable with a TBS if and only if
where UT = is the processor utilization of the
sporadic tasks and US is the processor utilization of the TBS.

22. Four Bandwidth-Preserving Servers
Deferrable Servers (1987).
Oldest and simplest of the bandwidth-preserving servers.
Static-priority algorithms by Lehoczky, Sha, and Strosnider.
Deadline-driven algorithms by Ghazalie and Baker (1995).
Sporadic Servers (1989).
Static-priority algorithms by Sprunt, Sha, and Lehoczky.
Total Bandwidth Servers (1994, 1995).
Deadline-driven algorithms by Spuri and Buttazzo.
Constant Utilization Servers (1997).
Deadline-driven algorithms by Deng, Liu, and Sun.
Sporadic servers are a type of bandwidth preserving server designed to eliminate the double-hit demand that deferrable servers can produce, such that the server can be treated exactly like a sporadic task for schedulability purposes. Constant utilization servers are similar to TBS, but are intended for scheduling hard aperiodic jobs accepted by servers. For hard aperiodic jobs, we don’t care so much that we improve their response time as we care that their deadlines are met. Constant utilization servers just ensure jobs meet their deadlines and dials back the response time reduct that a TBS would give to hard aperiodic jobs. More information can be found for these servers in Jim Anderson’s Real-Time Systems notes.

23. Real-Time Operating Systems (RTOSs)

24. Capabilities of Commercial RTOSs
We will look at these RTOSs:
LynxOS, Nucleus RTOS, and VxWorks.
Each of these systems shares the following attributes:
Compliant or partially compliant to the Real-Time POSIX API Standard:
Preemptive, fixed-priority scheduling.
Standard synchronization primitives (mutex and message passing).
Each also has its own API.
Modular and scalable:
The kernel is small so that it can fit in ROM in embedded systems.
I/O, file, and networking modules can be added.

25. Shared Attributes (Continued)
Fast and efficient:
Most are microkernel systems.
Low overhead.
Small context switch time, interrupt latency, and semaphore get/release latency: usually one to a few microseconds.
Nonpreemptable portions of kernel functions are highly optimized, short, and as deterministic as possible.
Many have system calls that require no trap: applications run in kernel mode.
Support split interrupt handling.
Flexible scheduling:
All offer at least 32 priority levels: min required by real-time POSIX.
Most offer 128 or 256 priority levels.
FIFO or RR scheduling for equal-priority threads.
Can change priorities, but EDF scheduling is not supported.
Microkernels, unlock Monolithic OS’s, implement the bare functionality of an OS in the kernel, and leave secondary services (file systems, network stack, etc.) to plugins added to the kernel. This creates a more modular OS but may produce higher interrupt latencies when the kernel is performing plugin-related tasks.
At 256 priority levels, the loss in schedulability over an infinity number of priority levels is relatively insignificant.

26. Shared Attributes (Continued)
Relatively High Clock and Timer Resolution:
No Paging or Swapping:
May not offer memory protection: often the kernel and all tasks execute in kernel mode, sharing one common address space.
Level of memory protection may be settable (ranging from “none” to “private virtual memory”).
Optional Networking Support:
Can be configured to support TCP/IP with an optional module.

27. LynxOS Based on a microkernel, which provides:
scheduling, interrupt dispatch, and synchronization.
Kernel Plug-Ins (KPIs) are lightweight multi-threaded kernel service modules that can be added so that:
LynxOS can serve as a multi-purpose Unix OS.
LynxOS can emulate Linux and UNIX system call APIs.
LynxOS can be configured as a self-hosted system.
Embedded applications are developed on the same system on which they are deployed and run (simplifies development and debugging).
Thus, LynxOS also provides optional memory protection (with an MMU) and demand paging.

28. Nucleus RTOS Designed for embedded applications.
Reported to have been shipped in over 3 Billion devices.
Automation, consumer electronics, cell phones, navigation, medical devices, …
Can be shrunk to fit into 13 KB memory.
More recently: 2 KB of flash
POSIX and ITRON support.
Can be scaled up to larger systems.
MMU support.
USB, multimedia, networking, etc.
Development must occur on a Windows or Linux host.
ITRON: OS api, used by many Asian car and consumer electronics manufacturers.
Deeply embedded OS: Designed to minimize memory footprint, power consumption, and overheads associated with various layers of abstraction (address-space separation between kernel and user)

29. VxWorks Used on the Mars Pathfinder:
Shortly after landing, Pathfinder was resetting. This was due to a classical uncontrolled priority inversion problem. The system was detecting a missed deadline and forcing a reset.
VxWorks supports the Priority Inheritance Protocol (PIP), but it is disabled by default.
A simple patch enabled the PIP and saved the day!
VxWorks is one of the few RTOSs that is a monolithic system rather than being based on a microkernel.
However, it does allow major functions, such as memory protection and priority inheritance, to be disabled.
Supports POSIX and most POSIX real-time extensions.

30. VxWorks (Continued)
Recent releases of VxWorks advertise multicore support.
Provides virtual-to-physical address mapping using an MMU if one is available.
Can make portions of memory non-cacheable.
The Eclipse-based Workbench tools create a cross-platform development environment:
These tools execute on a host machine and communicate with the target over an I/O interface.

31. PREEMPT_RT
A patch against mainline Linux to make Linux more “real-time friendly.”
Key features:
Reduced interrupt latencies.
Priority inheritance.
High-resolution timers.
Split interrupt handling.
Many of these features have since been integrated into mainline Linux.
The official goal was for PREEMPT_RT to eventually be completely merged into mainline Linux.
Development on PREEMPT_RT, however, has slowed recently

32. Linux with PREEMPT_RT The Good: The Bad: The Ugly:
100 total priority levels by default.
Linux provides flexible scheduling policies and a limited notion of servers/containers.
Well-supported and rich software development environment: standard compilers, standard libraries, file systems, etc.
You have the source. So if you don’t like something, change it!
The Bad:
Compared to other embedded RTOSs, Linux has high resource requirements.
The Ugly:
Linux is a monolithic kernel (not a microkernel) with sometimes-complex dependencies, and some parts aren’t well-documented.
So, some changes are easier said than done.

33. Linux: Scheduling 100 Priority Levels
Linux provides SCHED_FIFO, SCHED_RR and SCHED_OTHER scheduling policies.
SCHED_FIFO and SCHED_RR are fixed-priority algorithms for real-time processes.
SCHED_OTHER is a time-sharing algorithm for non-real-time processes, which execute at a lower priority than real-time processes. Limited bandwidth enforcement is available.
Recently, SCHED_DEADLINE was added.
SCHED_DEADLINE: a version of the EDF algorithm

34. LITMUSRT
LInux Testbed for MUltiprocessor Scheduling in Real-Time systems.
UNC’s real-time patch against stock Linux.
Focus: scheduling and synchronization.
Does not address other areas (such as interrupt handling, memory footprint).
A research tool, not a complete RTOS.
Future direction.
Rebase on top of PREEMPT_RT.
Power-aware? Frequency-scaling?
Heterogeneous platforms?