REAL-TIME MICHAEL ROITZSCH

(1)

Department of Computer Science Institute for System Architecture, Operating Systems Group

REAL-TIME

MICHAEL ROITZSCH

(2)

TU Dresden MOS – Real-Time

OVERVIEW

2

(3)

SO FAR

3

■ talked about in-kernel building blocks:

■ _threads

■ _memory

■ _IPC

■ drivers enable access to a wide range of non-kernel resources

■ need to manage resources

(4)

COURSE EIP

4

Basic Abstractions System Services

Applications

(5)

RESOURCES

5

Disk Bandwidth Network I/O

Files TCP/IP Sessions

Threads Memory

Semaphores

Communication Rights

Windows

Memory

(6)

TIME

6

(7)

COMPARISON

7

Memory Time

■ discrete, limited ■ continuous, infinite

■ hidden in the system ■ user-perceivable

■ managed by pager ■ managed by scheduler

■ page-granular partitions ■ arbitrary granularity

■ all pages are of equal value ■ value depends on workload

■ active policy decisions, passive enforcement

■ active policy decisions, active enforcement

■ hierarchical management ■ Fiasco: flattened in-kernel view

(8)

HISTORY

8

■ in the early years of computing:

time coarsely managed by batch systems

■ jobs receive the entire machine or a dedicated part of it for a given time

■ accounting, budgeting

■ no preemption

■ no interaction, good utilization

■ still prevalent in HPC systems

(9)

THREADS

■ today: threads provide a CPU abstraction

■ each thread should observe its own time as continuous

■ if there are more threads than physical CPU cores, we have to multiplex

■ enforced by preemption

■ implemented with timer interrupt

9

(10)

PROGRESS

10

wall-clock time

thread progress

(11)

REAL-TIME

11

(12)

DEFINITION

12

■ a real-time system denotes a system,

whose correctness depends on the timely delivery of results

■ „it matters, when a result is produced“

■ real-time denotes a predictable relation

between system progress and wall-clock

time

(13)

INTUITION

■ real-time is about

■ predictability

■ _guarantees

■ _timeliness

■ responsiveness

■ real-time is not about

■ _{being fast}

■ live calculations

13

(14)

NON-EXAMPLE

■ game engines

■ rendered frames are delivered at instances of wall-clock time, but

■ there is no guaranteed (minimal) frame-rate

■ rendering times are not even predictable

■ guaranteed responsiveness?

■ game engines are just fast (hopefully), but not real-time

14

(15)

EXAMPLES

focused catastrophic failures

■ engine control in a car

■ break-by-wire

■ _avionics

■ railway control

■ set-top box DVD player

■ GSM-stack in your cell phone

15

benign failures complex

(16)

FLAVORS

16

hard

real-time

firm

real-time

soft

real-time

missing some deadlines is

tolerable

✘ ✔ ✔

a result delivered after its deadline is

still useful

✘ ✘ ✔

(17)

THEMES

17

➀ Predictability

➁ ^Guarantees

➂ Enforcement

(18)

PREDICTABILITY

18

(19)

ENEMIES

19

■ gap between worst and average case

■ memory caches, disk caches, TLBs

■ „smart“ hardware

■ system management mode

■ disk request reordering

■ cross-talk from resource sharing

■ servers showing O(n) behavior

■ unpredictable external influences

■ _interrupts

(20)

CROSSCUTTING

20

Kernel System Services Applications

Hardware

Realtime

(21)

CUSTOM RTOS

■ small real-time executives tailor-made for specific applications

■ fixed workload known a priori

■ pre-calculated time-driven schedule

■ used on small embedded controllers

■ benign hardware

21

(22)

RTLINUX

■ full Linux kernel and real-time processes run side-by-side

■ small real-time executive underneath supports scheduling and IPC

■ real-time processes implemented as kernel modules

■ all of this runs in kernel mode

■ no isolation

22

(23)

XNU

■ the kernel used in Mac OS X

■ implements four priority bands

■ _normal

■ system high priority

■ kernel threads

■ real-time threads

■ you tell the kernel: I need A out of the next B cycles, can be contiguous

23

(24)

XNU

■ normal users can create real-time threads

■ threads exceeding their quantum will be demoted

■ with the first real-time thread, the kernel switches from using continuations to

full preemptibility

■ all drivers need to handle interrupts correctly

24

(25)

FIASCO

25

■ static thread priorities

■ bounded interrupt latency

■ fully preemptible in kernel mode

■ lock-free synchronization

■ uses atomic operations

■ wait-free synchronization

■ locking with helping instead of blocking

(26)

SKEPTICISM

26

Non-Real-Time Kernel Real-Time Middleware

Applications

■ architecture for those afraid of touching the OS

■ example: Real-Time Java

☹

(27)

RESOURCES

■ a real-time kernel alone is not enough

■ the microkernel solution:

■ real-time kernel enables temporal isolation

■

eliminates cross-talk and interrupt problems

■ user-level servers on top act as resource managers

■

implement real-time views on specific resources

■ real-time is not only about CPU

■ details in the resource management lecture

27

(28)

GUARANTEES

28

(29)

PROBLEM

■ worst case execution time (WCET) largely exceeds average case

■ offering guarantees for the worst case will waste lots of resources

■ missing some deadlines can be tolerated with the firm and soft real-time scheme

29

(30)

MOTIVATION

30

■ desktop real-time

■ there are no hard real-time applications on desktops

■ there is a lot of firm and soft real-time

■ low-latency audio processing

■ smooth video playback

■ desktop effects

■ user interface responsiveness

(31)

H.264 DECODING

31

0%

5%

10%

15%

0 5 10 15 20 25 30 ms

WCET

(32)

KEY IDEA

32

■ guarantees even slightly below 100% of WCET can dramatically reduce resource allocation

■ unused reservations will be used by others at runtime

■ use probabilistic planning to model the actual execution

■ quality q: fraction of deadlines to be met

(33)

KEY IDEA

33

WCET

(34)

RESERVATION

34

J J

r

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

(a) J successful because e ≤ r

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

(b) J unsuccessful be- cause e > r

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T_i T_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f.

q r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r1 r2 r

Y2 aborted

X1 X2 Y1 Y2

0 d

r₁

r2

X₁ Y₁ X₂ Y₂

0 d

r₁ r2

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

(c) J unsuccessful although e ≤ r

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T_i T_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f.

q r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r1 r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

Figure 1. Successful and unsuccessful jobs

an admission using WCET, the reservation time is only the fraction of the WCET ensuring a requested quality q. A probabilistic model exactly mapping this scheduling policy enables the computation of these.

The reservation time r appears to result solely from the q-quantile of the execution time distribution of the jobs (see Figures 1a and 1b). However, the model also has to consider a job J being aborted at its relative deadline d even if a complete execution of the job would not have exhausted its reservation time (see Figure 1c).

Hence, the reservation time for each job J of a task re- questing a quality q is the shortest time r where

P(J does not run longer than r ∧

J is completed until its relative deadline) ≥ q (1) More formally, let p_i(r) denote the probability that a job of task T_i is completed in the sense of Equation (1) (r ∈ R, i ∈ N). Then we obtain a system of equations for a task set T = {T¹, . . . , T_n} with requested qualities q^1, . . . , q_n:

r_i = min(r ∈ R | pⁱ(r) ≥ qⁱ) ∀i = 1, . . . , n. (2) So the general admission criterion is

The system of equations in (2) is solvable. (3)

2.2. Task Model

Generally, we consider tasks T_i as a sequence of jobs J_ij to be processed periodically:

T_i = (J_ij)_j=1,2,... i = 1, . . . , n (4)

where n ∈ N denotes the total number of tasks in the task set T = {T¹, . . . , T_n}.

To be widely applicable, we want to map both hard and firm real-time tasks in both preemptible and nonpreemptible flavor to our model. Therefore, each job can be partitioned into one mandatory part M_ij and m_i optional parts O_ij1, O_ij2, . . . , O_ijm. M_ij is released at the begin- ning of its respective period, O_ij1 becomes ready when M_ij is completed, and so on. The end of the period is the relative deadline of all parts. The execution times of the parts vary described by random variables, but obviously the manda- tory parts do not exceed their WCET, w_i. We assume that the random variables of all tasks are pairwise independent.

For a task T_i, the random variables describing the individ- ual instances of the mandatory part are assumed to be identically distributed. The same is assumed for the instances of the optional parts. Finally, an application may specify a minimum percentage, q_i, of optional parts that have to be completed successfully. In summary, the following definition describes a task.

Definition 1 A task Ti is a tuple

T_i = (X_i, Y _i, w_i, m_i, q_i, d_i) (5) where

X_i nonnegative random variable: execution time of a mandatory part,

Y_i nonnegative random variable: execution time of an optional part,

w_i positive real number less than or equal to d_i: worst case execution time of the mandatory parts,

m_i nonnegative integer: number of optional parts, q_i real number 0 ≤ qⁱ ≤ 1: quality parameter,

probability that an optional part is completed, d_i positive real number: period length = relative

deadline.

Further generalizations (task offsets, not identically distributed optional parts) increase the effort to formulate the admission criterion (more variables, more indices), without increasing the tractability or the computational complexity. For simplicity, we identify the parts with their random variables, consider each mandatory part M_ij as a realiza- tion of X_i and each O_ijk as a realization of Y_i. Notably, m_i = 0 enables us to model hard real-time tasks, X_i ≡ 0 and m_i = 1 models a set of “classical” firm tasks (as in [12, 2]).

The admission goal is to derive the priorities pr(X_i) and pr(Y_i) of the mandatory and optional parts and the reserva- tion times r_i from the task description listed above in such a way that a feasible schedule can be generated, by which is meant all mandatory parts meet their deadlines and all optional parts meet their quality requirements. We describe

(35)

RESERVATION

35

preemptible (CPU) as well as for nonpreemptible (disk) re- sources. Furthermore, we also included empirical execution time distributions. Three main conclusions should be em- phasized here.

• All the experiments show the compliance of the re- quested qualities with the achieved qualities.

• The approach enables to provide statistical guarantees and to control the behavior of firm applications even under overload.

• QAS can clearly admit a higher load than an admission based on WCET with negligible loss of quality.

The costs for these advantages are comparatively low. The numerical complexity of the admission control (which can be done offline) is dominated by the convolution of the dis- cretized execution time distributions. The highest complex- ity is that for the admission in case of nonpreemptible re- sources; their complexity is O(s · v

³

) (s: total number of optional parts, v: common number of values of the ran- dom variables) [10, 11]. On the other hand, the scheduler only manages the ready queue based on fixed priorities. So online-overhead is negligible, independent of the type of re- sources and the type of periods.

In case of arbitrary periods however, the computation of the reservation time is very expensive with increasing costs for larger task sets because the hyperperiod explodes for task sets with close-by period lengths (like 503 and 510) and all periods must be considered. Looking for a way to overcome this difficulty, we propose a new admission con- trol approach, which differs from QAS in three respects:

priority assignment, interpretation of the reservation time, and as a consequence, a very low-cost admission algorithm.

4. Quality-Rate-Monotonic Scheduling

We will first explain our new approach, followed by an investigation of the admission performance and overhead.

4.1. The QRMS Approach

QRMS is simple but still effective. We abandon the ex- act modeling of the scheduling behavior in favor of apply- ing the well-known results from rate-monotonic scheduling theory. Therefore, we choose another priority assignment policy and a simpler way to compute the reservation times:

• Priorities are assigned to tasks (this means mandatory and optional parts of a task have the same priority) ac- cording to RMS.

• All parts of a job are assigned a common reservation time.

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T

_i

T

_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f. q

r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r₁ r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

(a) QAS

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T

_i

T

_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f.

q r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r₁ r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

(b) QRMS

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T_i T_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f.

q r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r₁ r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

Figure 4. Admission with QAS vs. QRMS

• In the admission, the reservation time is regarded as a constant execution time.

Consequently, tasks are independent during admission, an important advantage to drastically decrease the admission overhead. Figure 4 illustrates the modified priority assign- ment and the notion of reservation times for two tasks T

₁

, T

₂

with uniform periods of length d.

The approach uses the task model given in Definition 1.

To derive the reservation times, we consider preemptible resources first. We have to use Equation (8). Due to the laws of probability calculus, we can compute the expected value of A

_i

as

EA

_i

=

m_i

!

k=1

P(A

_i

≥ k), i = 1, . . . , n (9) The number A

_i

of completed parts of task T

_i

within a period does no longer depend on the reservation times of other tasks. Obviously, it holds (see Figure (5)):

P(A

_i

(r) ≥ k) = P(X

ⁱ

+ k · Y

ⁱ

≤ r), k = 1, . . . , m

ⁱ

Thus: (10)

r

_i^!

= min(r ∈ R |

m_i

!

k=1

P(X

_i

+ k · Y

ⁱ

≤ r) ≥ q

ⁱ

m

_i

) . (11) The final formula respects the fact that r

_i^!

may be shorter than the WCET w

_i

of the mandatory part and includes the constraint that jobs are aborted at the end of their period:

r

_i

= max(r

_i^!

, w

_i

) i = 1, . . . , n (12) We check r

_i

≤ d

ⁱ

for all i in a first admission step. Then the final admission test can be done using the Liu/Layland- criterion or time demand analysis [13]. In case of nonpre- emptible resources, r

_i^!

is computed as above, but the admis- sion must include the WCET w

_O,i

of an optional part:

r

_i

= max(r

_i^!

+ w

_O,i

, w

_i

) (13)

■ to fully understand this:

see real-time systems lecture

■ good for microkernel: reservation can be calculated by a userland service

■ kernel only needs to support static priorities

preemptible (CPU) as well as for nonpreemptible (disk) resources. Furthermore, we also included empirical execution time distributions. Three main conclusions should be em- phasized here.

• All the experiments show the compliance of the re- quested qualities with the achieved qualities.

• The approach enables to provide statistical guarantees and to control the behavior of firm applications even under overload.

• QAS can clearly admit a higher load than an admission based on WCET with negligible loss of quality.

The costs for these advantages are comparatively low. The numerical complexity of the admission control (which can be done offline) is dominated by the convolution of the dis- cretized execution time distributions. The highest complexity is that for the admission in case of nonpreemptible re- sources; their complexity is O(s · v³) (s: total number of optional parts, v: common number of values of the ran- dom variables) [10, 11]. On the other hand, the scheduler only manages the ready queue based on fixed priorities. So online-overhead is negligible, independent of the type of resources and the type of periods.

In case of arbitrary periods however, the computation of the reservation time is very expensive with increasing costs for larger task sets because the hyperperiod explodes for task sets with close-by period lengths (like 503 and 510) and all periods must be considered. Looking for a way to overcome this difficulty, we propose a new admission control approach, which differs from QAS in three respects:

priority assignment, interpretation of the reservation time, and as a consequence, a very low-cost admission algorithm.

4. Quality-Rate-Monotonic Scheduling

We will first explain our new approach, followed by an investigation of the admission performance and overhead.

4.1. The QRMS Approach

QRMS is simple but still effective. We abandon the ex- act modeling of the scheduling behavior in favor of apply- ing the well-known results from rate-monotonic scheduling theory. Therefore, we choose another priority assignment policy and a simpler way to compute the reservation times:

• Priorities are assigned to tasks (this means mandatory and optional parts of a task have the same priority) ac- cording to RMS.

• All parts of a job are assigned a common reservation time.

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T_i T_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f. q

r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r₁ r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r2

X1 Y1 X2 Y2

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

(a) QAS

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

d_i

T_i T_j

d_j

t p.d.f.

q r

d

…

^J

e t

p.d.f.

q r e d

…

^J

p.d.f.

q r d t

…

^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r₁ r₂ r

Y₂ aborted

X₁ X₂ Y₁ Y₂

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r₁ r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 d_i

r

(b) QRMS

1a 1b 1c

Figure 2. Reservation times of optional parts

Figure 3. Overlapping periods

a) QAS b) QRMS Figure 4. Admission with QAS vs. QRMS

Figure 5.

aborted part of J

di

T_i T_j

dj

t p.d.f.

q r

d

… ^J

e t

p.d.f.

q r e d

… ^J

p.d.f.

q r d t

… ^J

e

X₁ X₂ X₃ Y₁ Y₂ Y₃

d 0

r1 r2 r

Y2 aborted

X1 X2 Y1 Y2

0 d

r₁

r₂

X₁ Y₁ X₂ Y₂

0 d

r1 r₂

lost for admission available for admission

X_i Y_i Y_i Y_i Y_i

0 di

r

Figure 4. Admission with QAS vs. QRMS

• In the admission, the reservation time is regarded as a constant execution time.

Consequently, tasks are independent during admission, an important advantage to drastically decrease the admission overhead. Figure 4 illustrates the modified priority assign- ment and the notion of reservation times for two tasks T₁, T₂ with uniform periods of length d.

The approach uses the task model given in Definition 1.

To derive the reservation times, we consider preemptible resources first. We have to use Equation (8). Due to the laws of probability calculus, we can compute the expected value of A_i as

EA_i =

m_i

!

k=1

P(A_i ≥ k), i = 1, . . . , n (9) The number A_i of completed parts of task T_i within a period does no longer depend on the reservation times of other tasks. Obviously, it holds (see Figure (5)):

P(A_i(r) ≥ k) = P(Xⁱ + k · Yⁱ ≤ r), k = 1, . . . , mⁱ Thus: (10)

r_i^! = min(r ∈ R | 1 m_i

m_i

!

k=1

P(X_i +k ·Yⁱ ≤ r) ≥ qⁱ). (11) The final formula respects the fact that r_i^! may be shorter than the WCET w_i of the mandatory part and includes the constraint that jobs are aborted at the end of their period:

r_i = max(r_i^!, w_i) i = 1, . . . , n (12) We check r_i ≤ dⁱ for all i in a first admission step. Then the final admission test can be done using the Liu/Layland- criterion or time demand analysis [13]. In case of nonpre- emptible resources, r_i^! is computed as above, but the admis- sion must include the WCET w_O,i of an optional part:

r_i = max(r_i^! + w_O,i, w_i) (13)

(36)

SCHEDULING

■ scheduling = admission + dispatch

■ _admission

■ evaluates the requests from clients, which follow some task model

■ calculates task parameters for dispatcher

■ verifies the feasibility of the guarantees

■ can reject requests

■ _dispatch

■ executes and enforces the schedule

36

(37)

ENFORCEMENT

37

(38)

DISPATCHER

38

■ executes schedule

■ enforces task parameters by preemption

■ e.g. on deadline overrun

■ picks the next thread

■ static priorities (e.g. RMS, DMS)

■ dynamic priorities (e.g. EDF)

■ seems simple …

(39)

PROBLEM

39

■ high priority thread calls low priority service with a medium priority thread interfering:

Thread 1 Thread 2 Thread 3

Priority

1 waits for 3 3 waits for 2

= 1 waits for 2

✔

✘ Priority Inversion

(40)

SOLUTION

■ priority inheritance, priority ceiling

■ nice mechanism for this in Fiasco, NOVA:

timeslice donation

■ implemented by splitting thread control block

■

execution context: holds CPU statue

■

scheduling context: time and priority

■ on IPC-caused thread switch, only the execution context is switched

40

(41)

DONATING CALL

41

Thread 1 Thread 2 Thread 3

Priority

■ IPC receiver runs on the sender‘s scheduling context

■ priority inversion problem solved with

priority inheritance

(42)

ACCOUNTING

■ servers run on their clients time slice

■ when the server executes on behalf of a client, the client pays with its own time

■ this allows for servers with no scheduling context

■ server has no time or priority on its own

■ can only execute on client‘s time

■ relieves dispatcher from dealing with servers

42

(43)

TIMELESS

■ servers could be malicious, so you need timeouts to get your time back

■ now, malicious clients can call the server with a very short timeout

■ server‘s time will be withdrawn while the server is in the middle of request handling

■ servers need to do session cleanup

■ on whose time?

■ open research problem

43

(44)

SMP

■ timeslice donation does not work in multiprocessor case:

■ server is running on a different CPU

■ cross-CPU donation would be needed

■ you cannot donate time between CPUs

■ think of real-time guarantees

■ if one CPU is 100% loaded, donating time to it will overload it

■ servers need to migrate to client CPU?

44

(45)

OPTIMIZATION

45

(46)

SEMAPHORES

46

Thread 1

Thread 2 Semaphore

Thread

down

enqueue and block

up

dequeue and unblock

up

■ IPC only in the contention case

■ optimized for low contention

■ bad for producer-consumer (high contention)

(47)

SCENARIO

■ _consumer

■ request wakeup: set flag, enqueue

■ _block

■ _producer

■ check for wakeup: test flag, dequeue

■ send wakeup

■ very short critical sections

■ semaphores too expensive (2 IPCs)

47

(48)

IDEA

■ allow threads to have short periods where they are never preempted

■ like a very low cost global system lock

■ delayed preemption

■ threads can set „don‘t preempt me“ flag in UTCB

■ very low cost

48

(49)

PROBLEMS

■ unbounded delay

■ if preemption would occur, the kernel

honors the delayed preemption flag only for a fixed maximum delay

■ delay affects all threads

■ problematic for real-time guarantees

■ affected threads can be limited to those within a priority band

■ other threads can still preempt any time

49

(50)

REAL-TIME MICHAEL ROITZSCH

REAL-TIME

MICHAEL ROITZSCH

OVERVIEW

SO FAR

■ talked about in-kernel building blocks:

■ threads

■ memory

■ IPC

■ drivers enable access to a wide range of non-kernel resources

■ need to manage resources

COURSE EIP

Basic Abstractions System Services

Applications

RESOURCES

Disk Bandwidth Network I/O

Files TCP/IP Sessions

Threads Memory

Semaphores

Communication Rights

Windows

Memory

TIME

COMPARISON

HISTORY

■ in the early years of computing:

time coarsely managed by batch systems

■ jobs receive the entire machine or a dedicated part of it for a given time

■ accounting, budgeting

■ no preemption

■ no interaction, good utilization

■ still prevalent in HPC systems

THREADS

■ today: threads provide a CPU abstraction

■ each thread should observe its own time as continuous

■ if there are more threads than physical CPU cores, we have to multiplex

■ enforced by preemption

■ implemented with timer interrupt

PROGRESS

REAL-TIME

DEFINITION

■ a real-time system denotes a system,

whose correctness depends on the timely delivery of results

■ „it matters, when a result is produced“

■ real-time denotes a predictable relation

between system progress and wall-clock

time

INTUITION

■ real-time is about

■ predictability

■ guarantees

■ timeliness

■ responsiveness

■ real-time is not about

■ being fast

■ live calculations

NON-EXAMPLE

■ game engines

■ rendered frames are delivered at instances of wall-clock time, but

■ there is no guaranteed (minimal) frame-rate

■ rendering times are not even predictable

■ guaranteed responsiveness?

■ game engines are just fast (hopefully), but not real-time

EXAMPLES

■ engine control in a car

■ break-by-wire

■ avionics

■ railway control

■ set-top box DVD player

■ GSM-stack in your cell phone

FLAVORS

✘ ✔ ✔

✘ ✘ ✔

THEMES

➀ Predictability

➁ Guarantees

➂ Enforcement

PREDICTABILITY

ENEMIES

■ gap between worst and average case

■ _threads

■ _memory

■ _IPC

■ _guarantees

■ _timeliness

■ _{being fast}

■ _avionics

➁ ^Guarantees

■ _interrupts

■ _normal