Real-time concepts

Lin ZhongELEC424, Fall 2010

Real time

• Correctness – Logical correctness– Timing

• Hard vs. Soft– Hard: lateness is intolerable

• Pass/Fail courses

– Soft: lateness can be tolerated but penalized• Regular courses

2

Non real-time Soft real-time Hard real-time

Example real-time systems

• Hard real-time systems– Target acquisition system on jet fighters– Electronic engine control unit

• Fuel injection• Ignition timing

– Anti-lock braking system (ABS)– Air traffic control– Reservation system

• ………

3

Example real-time systems

• Soft real-time system– Media player– WiFi interface card

4

Model of a system

5

Execution of tasks

Arrival of requests

Key question

• Can the system finish the requests in time? (Feasibility analysis)

Key variables

• Execution of requests– Predictability

• Probabilistic distribution of execution time– Range: Worst case execution time

• Arrival of requests– Predictability

• Probabilistic distribution of arrival intervals– Range: worst case

6

Tasks: unit of scheduling

• OS-based real-time system– Process, threads

• OS-less real-time system– Interrupt handlers

• Periodic vs. Aperiodic

7

Model of a system

8

Execution of tasks

Task 2

Task 1

• Feasibility analysis

Assumptions• There are multiple tasks

– ti, i=1,…,m

• Tasks are periodic– Ti

– Each occurrence is called a request

• Execution time for each task is known– Ci

• Pre-emptive• Tasks are prioritized• Task switching is instant

9

Liu, C. L.; Layland, J. (1973), "Scheduling algorithms for multiprogramming in a hard real-time environment", Journal of the ACM 20 (1): 46–61

10

Scheduling Priority assignment

Definition of feasibility

11

C1Pre-empted

T1

T2

C2

Task 1

Task 2

Every request of every task is finished before the next request of the task

Feasibility analysis

12

Given a set of tasks, how do we know if a feasible scheduling exists?

• Sufficient condition• Necessary condition

Fixed priority scheduling

• Each task has a fixed priority

• Rate monotonic scheduling (RMS)– Higher request rate (1/T) Higher priority

13

Theorem of RMS optimality

• A scheduling of a set of tasks is feasible if deadlines of all requests are met

• Given a set of tasks, If a feasible scheduling exists, the rate-monotonic scheduling is feasible

• RMS is the best in terms of feasibility– Give high priority tasks to high-rate tasks

14

Feasibility analysis

15

Given a set of tasks, how do we know if a feasible scheduling exists?

• Sufficient condition• Necessary condition

Given a set of tasks, how do we know if the RMS is feasible?

Necessary condition

• Utilization of a system=(busy time)/(total time)• Utilization factor for a set of tasks

– UF =Σ(Ci/Ti)

• Necessary condition of feasibility– UF≤1

16

Can we make the bound for necessary condition smaller?

Sufficient condition

• Theorem: if UF ≤ m(21/m-1), the set of tasks are feasible– m(21/m-1)ln(2)≈0.69

• The bound is TIGHT– There exists infeasible sets whose UF m(21/m-1)

• The opposite is NOT true– Average real utilization factors of feasible sets is about 88%

• Theorem: if ∏(Ci/Ti+1) ≤2, the set of tasks are feasible– Less pessimistic

17

Enrico Bini, Giorgio C. Buttazzo, Giuseppe M. Buttazzo, "Rate Monotonic Analysis: The Hyperbolic Bound," IEEE Transactions on Computers, vol. 52, no. 7, pp. 933-942, July, 2003.

Dynamic priority scheduling

• Earliest deadline first (EDF)– Higher priority to requests with earlier deadline

• The sufficient and necessary condition of feasibility– UF≤1

18

Assumptions• There are multiple tasks

– ti, i=1,…,m

• Tasks are periodic– Ti

– Each occurrence is called a request

• Execution time for each task is known– Ci

• Pre-emptive• Tasks are prioritized• Task switching is instant

19

?

Synchronization

20

C1Pre-empted

T1

T2

C2

Task 1

Task 2

Synchronization

• Task 1– A[0] accelerometer– B[0] A[0]

• Task 2– If(A[0]!=B[0) exit

21

LD R13, (A[0]);LD R14, (B[0]) ;CMP R13, R14;JEQ EXIT

Synchronization (Contd.)

22

• Critical section– Section of code that access a shared resource that must

not be concurrently accessed by more than one thread of execution

• Atomic operation– A set of operations that appears to be one to the system

• System state change due to the operations invisible until all the operations are successful

• If any of the operations fails, the entire set fails; and no change to the system state

– Assembly instruction– Disable interrupt

Lock-based synchronization

• Lock– Limited access to critical section

• Task 1– Lock(); A[0] accelerometer;– B[0] A[0];– Unlock();

• Task 2– Lock(); If(A[0]!=B[0) exit; unlock();

23

Lock implementation

• Lock() and unlock() must be atomic– A bit– Lock()

• Disable interrupt• check if the bit is set• if not, set it and enable interrupt; • else enable interrupt and wait;

– Unlock()• Disable interrupt• unset the bit;• Enable interrupt

24

Lock implementation (Contd.)

• Lock()– Disable interrupt– check if the bit is set– if not, set it and enable interrupt; – else enable interrupt and wait;

• Spinning– Keep on calling lock()

• Block– Sleep– The OS checks the bit and wake the blocked thread up to call

lock()

25

Lock implementation (Contd.)

• Task 1– Lock(); A[0] accelerometer;– B[0] A[0];– Unlock();

• Task 2– Lock(); If(A[0]!=B[0) exit; unlock();

26

Why don’t we simply replace lock() with disable_interrupt and unlock() with enable_interrupt?

Programming primitives

• Semaphore– A data structure for lock– Allow multiple access to the data structure

• Mutex– Binary semaphore

• Usually blocking

27

Problems with locks

• Priority inversion– A low-priority task has the lock but has been pre-

empted by a high-priority one• Deadlock

– Two tasks each are holding a lock that is needed by the other

• Convoying– Multiple threads with equal priority contend for

the same lockToo many context switches

28

Transaction memory

• Transaction– A series of speculated operations– Commit or abort

• Implementation– Hardware– Software

29

Herlihy, M. and Moss, J. E. 1993. Transactional memory: architectural support for lock-free data structures. SIGARCH Comput. Archit. News 21, 2 (May. 1993), 289-300

WWW

WWW

OS-less real-time system

• Latency in interrupt handling– Predictable

• Arrival of interrupts– Predictable (Periodic)– Unpredictable (Aperiodic)

• Any statistics?• Worst case?

30

TimerA() USARTRX()

Interrupt handlers

System idle

Interrupt Interrupt

Real-time operating system (RTOS)

• Interrupt latency– Interrupt controller– Interrupt masking– OS interrupt handling

• Thread switching latency

31

WWW