Notes - MIECT
Sistemas Operativos E De Tempo-real
Notes - MIECT
Sistemas Operativos E De Tempo-real
  • Sistemas Operativos e de Tempo-real
  • Basic Concepts About Real-Time Systems
    • Preliminaries
    • Definitions
    • Objective of the Study of RTS
    • Requirements of Real-Time Systems
  • Real Time Model
    • Real Time Model
    • Temporal Control
    • Task states and execution
    • Kernel/RTOS Architecture
      • Time Management Functions
    • Examples of RTOS
  • Practical Class 01
    • Real-Time Services in Linux
    • Using the Linux real-time services
  • Scheduling Basics
    • Basic concepts
    • Scheduling Algorithms
      • Basic algorithms
    • Static Cyclic Scheduling
    • Exercise
  • Fixed Priority Scheduling
    • Online scheduling with fixed priorities
    • Schedulability tests based on utilization
      • Deadline Monotonic Scheduling DM
    • Response-time analysis
  • Practical Class 2
    • Xenomai brief introduction
    • API
    • Developing an application
  • Dynamic Priority Scheduling
    • On-line scheduling with dynamic priorities
    • Analysis: CPU utilization bound
    • Analysis: CPU Load Analysis
    • Other deadline assignment criteria
  • Exclusive Access to Shared Resources
    • The priority inversion problem
    • Techniques for allowing exclusive access
    • Priority Inheritance Protocol
    • Priority Ceiling Protocol
    • Stack Resource Policy
    • Notes
  • Aperiodic Servers
    • Joint scheduling of periodic and aperiodic tasks
    • Aperiodic Servers
    • Fixed Priority Servers
    • Dynamic Priority Servers
  • Limited preemption, release jitter and overheads
    • Non-preemptive scheduling
    • Impact of Release Jitter
    • Accounting for overheads
    • Considerations about the WCET
  • Profiling and Code Optimization
    • Code optimization techniques
      • CPU independent optimization techniques
      • Cache impact
      • Optimization techniques dependent on memory architecture
      • Architecture-dependent optimization techniques
    • Profiling
  • Multiprocessor Scheduling, V1.2
    • Introduction
    • Definitions, Assumptions and Scheduling Model
    • Scheduling for Multicore Platforms
    • Task allocation
Powered by GitBook
On this page
  • Polling server (PS)
  • Tighter tests
  • Deferrable server (DS)
  • Sporadic server (SS) [Sprunt, Sha and Lehoczky, 89]
  • Illustration
  1. Aperiodic Servers

Fixed Priority Servers

PreviousAperiodic ServersNextDynamic Priority Servers

Last updated 2 years ago

Polling server (PS)

This fixed priority server is completely equivalent to the execution of a periodic task. The aperiodic requests are served only during the execution intervals granted to the server by the periodic task scheduler.

  • E.g. Polling server with (C , T ) = (1, 4)

The implementation of a polling server is relatively simple. It only requires a queue for the aperiodic requests and control of the capacity used.

The average response time to aperiodic requests is better than the one obtained with background execution, since it is possible to elevate the priority of the server. However it has relatively long unavailability periods.

The impact on the periodic task set is exactly the same as the one of a periodic task.

Utilization test for RM + PS

Tighter tests

The previous test (Liu & Layland bound) is independent of the utilization of each task. It is possible to improve the test (i.e. obtain tighter bounds).

Let Up and Us be the utilization factors of the periodic task set and polling server, resp.

RM + PS

RM + PS, Hyperbolic Bound

Deferrable server (DS)

The basic idea of this fixed-priority server is to handle aperiodic requests from the beginning of its execution until:

  • End of its period (TS) or

  • Its capacity (CS) gets exhausted.

The capacity is replenished at the beginning of each period.

  • E.g. Deferrable server with (C , T ) = (1, 4)

  • Simple implementation (similar to a PS).

  • The average response time to aperiodic requests is improved with respect to the PS, since it is possible to use the capacity of the DS during the whole period, provided that its capacity is not exhausted.

  • However, there is a negative impact on the schedulability of the periodic tasks. The reason for this impact is that the delayed executions increase the load on the future. E.g., it is possible having two consecutive executions (back-to-back execution).

RM + DS: Least Upper Bound

Illustration of a scenario in which replacing a periodic task by a DS causes deadline misses.

  • Periodic tasks.

  • Task 1 replaced by a DS.

Sporadic server (SS) [Sprunt, Sha and Lehoczky, 89]

The basic idea of this fixed-priority server is also allow the execution of the server at any instant (as the DS), however without penalizing the schedulability of the periodic system (as the PS).

The SS replenishes the capacity not at the end of the period but instead according with the time instants in which the capacity is actually used.

Definitions:

  • SS active : the server or hep(SS) tasks are executing

  • SS idle : processor idle or lp(SS) task executing

  • RT/RA : replenishing time/amount

Replenishment rules:

  • RT is set when SS becomes active and Cs > 0 (tA).

  • RA is computed when the SS becomes idle or Cs is exhausted (tI ). RA is the capacity used in the interval [ta , tI ]

Illustration

Periodic tasks

Sporadic server: SS : Cs = 5, Ts = 10

Priority assignment: RM (thus Pr (Ï„1 ) > Pr (Ï„s ) > Pr (Ï„2 ))

  • The implementation complexity of a sporadic server is higher than the one of PS and DS, due to the computation of the replenishment instants and, more importantly, to the complex timer management.

  • The average response time to aperiodic requests is similar to the one of the DS.

  • The impact on the schedulability of the periodic tasks is exactly the same as the one of the PS.

    • The SS executes as soon as it has capacity, but the technique used to replenish the capacity preserves the timing behavior and bandwidth (unlike the DS).

RM + SS utilization tests