Real Time Systems – Issues in Real Time Computing – Structure of a real time system – Process – Task – Threads.
Classification of Tasks – Task Periodicity – Periodic Tasks- Sporadic Tasks – Aperiodic Tasks – Task Scheduling –
Classification of Scheduling Algorithms – Event Driven Scheduling – Rate monotonic scheduling – Earliest deadline first scheduling.
Inter Process Communication:- Shared data problem, Use of Semaphore(s), Priority Inversion Problem and Deadlock Situations -
2. Real Time Operating Systems
Real Time Systems – Issues in Real Time Computing – Structure of a real time system –
Process – Task – Threads.
Classification of Tasks – Task Periodicity – Periodic Tasks- Sporadic Tasks – Aperiodic
Tasks – Task Scheduling –
Classification of Scheduling Algorithms – Event Driven Scheduling – Rate monotonic
scheduling – Earliest deadline first scheduling.
Inter Process Communication:- Shared data problem, Use of Semaphore(s), Priority
Inversion Problem and Deadlock Situations - Evaluating operating system performance –
Power optimization strategies for processes.
3. Embedded vs. Real Time Systems
• Embedded system: is a computer system that performs a limited set of specific functions. It
often interacts with its environment.
• RTS: Correctness of the system depends not only on the logical results, but also on the time
in which the results are produced.
Embedded
Systems
Real Time
Systems
4. Examples
• Real Time Embedded:
• Nuclear reactor control
• Flight control
• Basically any safety critical system
• GPS
• MP3 player
• Mobile phone
• Embedded, but not Real Time:
• Home temperature control
• Sprinkler system
• Washing machine, refrigerator, etc.
• Blood pressure meter
• Real Time, but not Embedded:
• Stock trading system
• Skype
• Pandora
5. Overview of Real-Time Systems
• Real-time systems have been defined as: ―those systems in which the correctness of the
system depends not only on the logical result of the computation, but also on the time at
which the results are produced―.
• A real-time system requires that results be produced within a specified deadline period.
• Correct function at correct time : Usually Embedded
• An embedded system is a computingdevice that is part of a larger system (I.e. automobile, airliner.)
6. Cont.
• A safety-criticalsystem is a real-time system with terrible results in case of failure.
Deadlines
• A hard real-time system guarantees that real-time tasks be completedwithin their required deadlines.
• No deadline miss is allowed.
• A soft real-time system provides priority of real-time tasks over non real-time tasks.
• Somedeadline miss is tolerated.
7. System Characteristics
• Single purpose
• Small size
• Inexpensively mass-produced
• Specific timing requirements
• Event-driven, reactive.
• High cost of failure.
• Concurrency/multiprogramming.
• Stand-alone/continuous operation.
• Reliability/fault-tolerance requirements.
• Predictable behavior.
8. Process
• Usually processes are not dedicated to processors
• A single queue is used for all processors
• if some sort of priority scheme is used, there are multiple queues based on priority
• System is viewed as being a multi-server queuing architecture
9. • In most traditional multiprocessor systems, processes are not dedicated to processors.
• Rather there is a single queue for all processors, or if some sort of priority scheme is used,
there are multiple queues based on priority, all feeding into the common pool of processors.
In any case, we can view the system as being a multiserver queuing architecture.
10. • With static assignment: should individual processors be multi programmed or should each
be dedicated to a single process?
• Often it is best to have one process per processor; particularly in the case of multithreaded
programs where it is advantageous to have all threads of a single process executing at the
same time.
11. Thread Scheduling
• Thread execution is separated from the rest of the definition of a process
• An application can be a set of threads that cooperate and execute concurrently in the same
address space
• On a uniprocessor, threads can be used as a program structuring aid and to overlap I/O with
processing
• In a multiprocessor system kernel-level threads can be used to exploit true parallelism in an
application
• Dramatic gains in performance are possible in multi-processor systems
• Small differences in thread management and scheduling can have an impact on applications
that require significant interaction among threads
12. • As we have seen, with threads, the concept of execution is separated from the rest of the
definition of a process. An application can be implemented as a set of threads, which cooperate
and execute concurrentlyin the same address space.
• On a uniprocessor, threads can be used as a program structuring aid and to overlap I/O with
processing. Because of the minimal penalty in doing a thread switch compared to a process
switch, these benefits are realized with little cost.
• However, the full power of threads becomes evident in a multiprocessor system. In this
environment, threads can be used to exploit true parallelism in an application.
• If the various threads of an application are simultaneously run on separate processors, dramatic
gains in performance are possible. However, it can be shown that for applications that require
significant interaction among threads (medium-grain parallelism), small differences in thread
management and scheduling can have a significant performanceimpact [ANDE89].
13. Load Sharing Gang Scheduling
Dedicated Processor Assignment Dynamic Scheduling
Four approaches for multiprocessor thread
scheduling and processor assignment are:
Approaches to Thread Scheduling
Processes are not
assigned to a particular
processor
a set of related thread scheduled
to run on a set of processors at
the same time, on a one-to-one
basis
Provides implicit scheduling defined
by the assignment of threads to
processors
The number of threads in a
process can be altered during the
course of execution
14. • Among the many proposals for multiprocessor thread scheduling and processor assignment, four general approaches
stand out:
• Load sharing : Processes are not assigned to a particular processor. A global queue of ready threads is
maintained, and each processor, when idle, selects a thread from the queue. The term load sharing is used to
distinguish this strategy from load-balancing schemes in which work is allocated on a more permanent basis (e.g.,
see [FEIT90a]). 2
• Gang scheduling : A set of related threads is scheduled to run on a set of processors at the same time, on a
one-to-one basis.
• Dedicated processor assignment: This is the opposite of the load-sharing approach and provides implicit
scheduling defined by the assignment of threads to processors. Each program, for the duration of its execution, is
allocated a number of processors equal to the number of threads in the program. When the program terminates, the
processors return to the general pool for possible allocation to another program.
• Dynamic scheduling: The number of threads in a process can be altered during the course of execution.
15. Load Sharing
• Simplest approach and carries over most directly from a uniprocessor
environment
• Versions of load sharing:
• first-come-first-served
• smallest number of threads first
• pre-emptive smallest number of threads first
Advantages:
• load is distributed evenly across the processors
• no centralized scheduler required
• the global queue can be organized and accessed using any of the schemesdiscussed in
Chapter 9
16. • Load sharing is perhaps the simplest approach and the one that carries over most directly
from a uniprocessor environment. It has several advantages:
• The load is distributed evenly across the processors, assuring that no processor is idle while
work is available to do.
• No centralized scheduler is required; when a processor is available, the scheduling routine
of the operating system is run on that processor to select the next thread.
• The global queue can be organized and accessed using any of the schemes discussed in
Chapter 9 , including priority-based schemes and schemes that consider execution history or
anticipated processing demands. [LEUT90] analyzes three different versions of load sharing:
17. • First-come-first-served (FCFS): When a job arrives, each of its threads is placed
consecutively at the end of the shared queue. When a processor becomes idle, it picks the
next ready thread, which it executes until completion or blocking.
• Smallest number of threads first: The shared ready queue is organized as a priority
queue, with highest priority given to threads from jobs with the smallest number of
unscheduled threads. Jobs of equal priority are ordered according to which job arrives first.
As with FCFS, a scheduled thread is run to completion or blocking.
• Preemptive smallest number of threads first: Highest priority is given to jobs with the
smallest number of unscheduled threads. An arriving job with a smaller number of threads
than an executing job will preempt threads belonging to the scheduled job.
18. System-on-a-Chip
• Many real-time systems are designed using system-on-a-chip (SOC) strategy.
• SOC allows the CPU, memory, memory-management unit, and attached peripheral ports
(I.e. USB) to be contained in a single integrated circuit.
• Reasons
• Real-time systems are typically single-purpose.
• Real-time systems often do not require interfacing with a user.
• Features found in a desktop PC require more substantial hardware that what is typically
available in a real-time system.
19. Definitions
• Hard real-time — systems where it is absolutely imperative that responses occur within the
required deadline. E.g. Flight control systems. (e.g., Avionics, Command & Control
Systems).
• Soft real-time — systems where deadlines are important but which will still function correctly
if deadlines are occasionally missed. (e.g. Data acquisition system, Video streaming).
• Real real-time — systems which are hard real-time and which the response times are very
short. (e.g. Missile guidance system).
• Firm real-time — systems which are soft real-time but in which there is no benefit from late
delivery of service. (e.g., Banking, Online transaction processing).
• A single system may haveall hard, soft and real real-time subsystems.
• In reality many systemswill have a cost function associated withmissing each deadline
20. Control systems
• Example:Asimple one-sensor, one-actuator control system.
control-law
computation
A/D
A/D
D/A
sensor plant actuator
rk
yk
y(t) u(t)
uk
reference
input r(t)
The system
being controlled
Outside effects
21. Control systems cont’d.
• Pseudo-code for this system:
set timer to interrupt periodically with period T;
at each timer interrupt do
do analog-to-digital conversion to get y;
compute control output u;
output u and do digital-to-analog conversion;
end do
T is called the sampling period.
• T is a key design choice.
• Typical range for T: seconds to milliseconds.
22. Example – Car driver
• Mission: Reaching the destination safely.
• ControlledSystem: Car.
• Operatingenvironment: Road conditions.
• ControllingSystem
• Human driver: Sensors - Eyes and Ears of the driver.
• Computer: Sensors - Cameras, Infrared receiver, Laser telemeter, Navigation system, Street maps.
• Controls:Accelerator, Steering wheel, Break-pedal.
• Actuators: Wheels, Engines, and Brakes.
23. • Critical tasks: Steering and breaking.
• Non-critical tasks: Turning on radio.
• Performance is not an absolute one. It measures the goodness of the outcome relative to
the best outcome possible under a given circumstance.
• Cost of fulfilling the mission → Efficient solution.
• Reliability of the driver → Fault-tolerance is a must.
27. Taxonomy: Static
• Task arrival times can be predicted
• Static (compile-time) analysis possible
• Allows good resource usage (low idle time for processors).
28. Taxonomy: Dynamic
• Arrival times unpredictable
• Static (compile-time) analysis possible only for simple cases.
• Processor utilization decreases dramatically.
• In many real systems, this is very difficult to handle.
• Must avoid over-simplifying assumptions
– e.g., assuming that all tasks are independent, when this is unlikely.
29. Taxonomy: Soft Real-Time
• Allows more slack in the implementation
• Timings may be suboptimal without being incorrect.
• Problem formulation can be much more complicated than hard real-time
• Two common and an uncommon way of handling non-trivial soft real-time
system requirements
– Set somewhat loose hard timing constraints
– Informal design and testing
– Formulate as an optimization problem
30. Taxonomy: Hard Real-Time
• Creates difficult problems.
• Some timing constraints are inflexible
• Simplifies problem formulation.
31. Taxonomy: Periodic
• Each task (or group of tasks) executes repeatedly with a particular period.
• Allows some static analysis techniques to be used.
• Matches characteristics of many real problems
• It is possible to have tasks with deadlines smaller, equal to, or greater than
their period.
• The latter are difficult to handle (i.e., multiple concurrent task instances occur).
32. Periodic
• Single rate:
• One period in the system
• Simple but inflexible
• Used in implementing a lot of wireless sensor networks.
• Multi rate:
• Multiple periods
• Should be harmonics to simplify system design
33. Taxonomy:Aperiodic
• Are also called sporadic, asynchronous, or reactive.
• Creates a dynamic situation
• Bounded arrival time interval are easier to handle
• Unbounded arrival time intervals are impossible to handle with resource-constrained
systems.
34. Example: Adaptive Cruise Control
• Control system
• Hard Real Time
• Multi-rate periodic
• Camera
• GPS
• Low-speed mode for rush hour traffic
35. Data Acquisition and Signal-Processing Systems
• Examples:
• Video capture.
• Digital filtering.
• Video and voice compression/decompression.
• Radar signal processing.
• Response times range from a few milliseconds to a few
seconds.
• Typically simpler than control systems
36. Other Real-Time Applications
• Real-time databases.
• Examples: stock market, airline reservations, etc.
• Transactions must complete by deadlines.
• Main dilemma: Transaction scheduling algorithms and real-time
scheduling algorithms often have conflicting goals.
• Data is subject temporal consistency requirements.
• Multimedia.
• Want to process audio and video frames at steady rates.
• TV video rate is 30 frames/sec. HDTV is 60 frames/sec.
• Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec.
• Other requirements: Lip synchronization, low jitter, low end-to-end
response times (if interactive).
37. Are All Systems Real-Time Systems?
• Question: Is a payroll processing system a real-time system?
• It has a time constraint: Print the pay checks every two weeks.
• Perhaps it is a real-time system in a definitional sense, but it
doesn’t pay us to view it as such.
• We are interested in systems for which it is not a priori obvious
how to meet timing constraints.
38. The “Window of Scarcity”
Resources may be categorized as:
• Abundant: Virtually any system design methodology can be used to realize
the timing requirements of the application.
• Insufficient: The application is ahead of the technology curve; no design
methodology can be used to realize the timing requirements of the
application.
• Sufficient but scarce: It is possible to realize the timing requirements of
the application, but careful resource allocation is required.
39. Ex: Interactive / Multimedia Applications
sufficient
but scarce
resources
abundant
resources
insufficient
resources
Requirements
(performance, scale)
1980 1990 2000
Hardware resources in year X
Remote
Login
Network
File Access
High-quality
Audio
Interactive
Video
The interesting
real-time
applications
are here
41. RTS Programming
• Because of the need to respond to timing demands made by different
stimuli/responses, the system architecture must allow for fast switching
between stimulus handlers.
• Because of different priorities, unknown ordering and different timing
requirements of different stimuli, a simple sequential loop is not usually
adequate.
• Real-time systems are therefore usually designed as cooperating processes
with a real-time kernel controlling these processes.
43. Implementing Real-Time Operating Systems
• In general, real-time operating systems must provide:
1. Preemptive, priority-based scheduling
2. Preemptive kernels
3. Latency must be minimized
44. Minimizing Latency
• Event latency is the amount of time from when an event occurs to when it
is serviced.
45. Interrupt Latency
• Interrupt latency is the period of time from when an interrupt arrives at the
CPU to when it is serviced.
46. Dispatch Latency
• Dispatch latency is the amount of time required for the scheduler to stop
one process and start another.
47. Real-Time CPU Scheduling
• Periodic processes require the CPU at specified intervals (periods)
• p is the duration of the period
• d is the deadline by when the process must be serviced
• t is the processing time
49. Rate Monotonic Scheduling
• A priority is assigned based on the inverse of its period
• Shorter periods = higher priority;
• Longer periods = lower priority
• P1 is assigned a higher priority than P2.
51. Earliest Deadline First Scheduling
• Priorities are assigned according to deadlines:
• the earlier the deadline, the higher the priority;
• the later the deadline, the lower the priority.
52. Tasks Categories
• Invocation
• Periodic (time-triggered)
• Aperiodic (event-triggered)
• Creation
• Static
• Dynamic
• Multi-Tasking System
• Preemptive: higher-priority process taking control of the processor from a
lower-priority
• Non-Preemptive : Each task can control the CPU for as long as it needs it.
53. Why we need scheduling ?!
• each computation (task) we want to execute needs resources
• resources: processor, memory segments, communication, I/O devices etc.)
• the computation must be executed in particular order (relative to each other
and/or relative to time)
• the possible ordering is either completely or statistically a priori known
(described)
• scheduling: assignment of processor to computations;
• allocation: assignment of other resources to computations;
54. Real-time Scheduling Taxonomy
• Job (Jij): Unit of work, scheduled and executed by system. Jobs repeated at
regular or semi-regular intervals modeled as periodic
• Task (Ti): Set of related jobs.
• Jobs scheduled and allocated resources based on a set of scheduling
algorithms and access control protocols.
• Scheduler: Module implementing scheduling algorithms
• Schedule: assignment of all jobs to available processors, produced by
scheduler.
• Valid schedule: All jobs meet their deadline
• Clock-driven scheduling vs Event(priority)-driven scheduling
• Fixed Priority vs Dynamic Priority assignment
55. Scheduling Periodic Tasks
In hard real-time systems, set of tasks are known apriori
Task Ti is a series of periodic Jobs Jij. Each task has the following parameters
ti - period, minimum interrelease interval between jobs in Task Ti.
ci - maximum execution time for jobs in task Ti.
rij - release time of the jth Job in Task i (Jij in Ti).
i - phase of Task Ti, equal to ri1.
ui - utilization of Task Ti = ci / ti
In addition the following parameters apply to a set of tasks
H - Hyperperiod = Least Common Multiple of pi for all i: H = lcm(pi), for all i.
U - Total utilization = Sum over all ui.
Schedulable utilization of an algorithm Us
If U < Us the set of tasks can be guaranteed to be scheduled
56. Real-Time Scheduling Algorithms
Fixed Priority Algorithms Dynamic Priority Algorithms Hybrid algorithms
Rate Monotonic
scheduling
Deadline
Monotonic
scheduling
Earliest
Deadline First
Least Laxity
First
Maximum
Urgency First
57. Scheduling Algorithm : Static vs. Dynamic
Static Scheduling:
All scheduling decisions at compile time.
Temporal task structure fixed.
Precedence and mutual exclusion satisfied by the schedule (implicit
synchronization).
One solution is sufficient.
Any solution is a sufficient schedulability test.
Benefits
Simplicity
58. • Dynamic Scheduling:
• All scheduling decisions at run time.
• Based upon set of ready tasks.
• Mutual exclusion and synchronization enforced by explicit
synchronization constructs.
• Benefits
• Flexibility.
• Only actually used resources are claimed.
• Disadvantages
• Guarantees difficult to support
• Computational resources required for scheduling
59. Preemptive vs. Non-preemptive
• Preemptive Scheduling:
• Event driven.
• Each event causes interruption of running tasks.
• Choice of running tasks reconsideredafter each interruption.
• Benefits:
• Can minimize response time to events.
• Disadvantages:
• Requires considerable computational resourcesfor scheduling
60. Cont.
• Non-preemptive Scheduling:
• Tasks remain active till completion
• Scheduling decisions only made after task completion.
• Benefits:
• Reasonable when
task execution times ~= task switching times.
• Less computational resources needed for scheduling
• Disadvantages:
• Can leads to starvation (not met the deadline) especially for those real time
tasks ( or high priority tasks).
61. Rate Monotonic scheduling
• Priority assignmentbased on rates of tasks
• Higher rate task assigned higher priority
• Schedulable utilization = 0.693 (Liu and Leyland)
Where Ci is the computation time, and Ti is the release period
• If U < 0.693, schedulability is guaranteed
• Tasks may be schedulable even if U > 0.693
62. Deadline Monotonic scheduling
• Priority assignmentbased on relative deadlines of tasks
• Shorter the relative deadline, higher the priority
63. Earliest Deadline First (EDF)
• Dynamic Priority Scheduling
• Priorities are assigned according to deadlines:
• Earlier deadline, higher priority
• Later deadline, lower priority
• The first and the most effectively widely used dynamic priority-
driven scheduling algorithm.
• Effective for both preemptive and non-preemptive scheduling.
64. Two Periodic Tasks
• Execution profile of two periodic tasks
• Process A
• Arrives 0 20 40 …
• Execution Time 10 10 10 …
• End by 20 40 60 …
• Process B
• Arrives 0 50 100 …
• Execution Time 25 25 25 …
• End by 50 100 150 …
• Question: Is there enough time for the execution of two periodic tasks?
66. Five Periodic Tasks
• Execution profile of five periodic tasks
Process Arrival Time
Execution
Time
Starting
Deadline
A 10 20 110
B 20 20 20
C 40 20 50
D 50 20 90
E 60 20 70
67.
68. Least Laxity First (LLF)
• Dynamic preemptive scheduling with dynamic priorities
• Laxity : The difference between the time until a tasks completion deadline
and its remaining processing time requirement.
• a laxity is assigned to each task in the system and minimum laxity tasks are
executed first.
• Larger overhead than EDF due to higher number of context switches caused
by laxity changes at run time
• Less studies than EDF due to this reason
69. Cont.
• LLF considers the execution time of a task, which EDF does not.
• LLF assigns higher priority to a task with the least laxity.
• A task with zero laxity must be scheduled right away and executed without preemption or it
will fail to meet its deadline.
• The negative laxity indicates that the task will miss the deadline, no matter when it is picked
up for execution.
71. Maximum Urgency First Algorithm
• This algorithm is a combination of fixed and dynamic priority scheduling, also called mixed
priority scheduling.
• With this algorithm, each task is given an urgency which is defined as a combination of two
fixed priorities (criticality and user priority) and a dynamic priority that is inversely
proportional to the laxity.
• The MUF algorithm assigns priorities in two phases
• Phase One concerns the assignment of static priorities to tasks
• Phase Two deals with the run-time behavior of the MUF scheduler
72. Maximum Urgency First Algorithm phase 1
The first phase consists of these steps :
1. It sorts the tasks from the shortest period to the longest period. Then it defines the
critical set as the first N tasks such that the total CPU load factor does not exceed
100%. These tasks are guaranteed not to fail even during a transient overload.
2. All tasks in the critical set are assigned high criticality. The remaining tasks are
considered to have low criticality.
3. Every task in the system is assigned an optional unique user priority
73. Maximum Urgency First Algorithm phase 2
In the second phase, the MUF scheduler follows an algorithm to select a
task for execution.
This algorithm is executed whenever a new task is arrived to the ready
queue.
The algorithm is as follows:
1) If there is only one highly critical task, pick it up and execute it.
2) If there are more than one highly critical task, select the one with the highest dynamic
priority. Here, the task with the least laxity is considered to be the one with the highest
priority.
3) If there is more than one task with the same laxity, select the one with the highest user
priority.