Real-Time Systems and Scheduling Theory

Introduction and Context

A real-time embedded system is one whose correctness depends not only on the logical result of computation but also on the time at which that result is produced. An automotive braking controller, implantable medical device, industrial protection relay, and flight-control computer may all produce numerically correct outputs yet fail if those outputs arrive too late. Real-time engineering therefore combines functional correctness with temporal correctness.

The central design problem is to allocate processor, memory, communication, and peripheral resources so that tasks complete within their timing constraints under specified operating conditions. This requires explicit models of task execution, deadlines, interference, response time, and overload. Scheduling theory supplies analytical methods for determining whether a system can meet these constraints before implementation and testing.

Real-time systems are commonly classified as hard, firm, or soft real-time systems. In a hard real-time system, missing a deadline can cause catastrophic or unacceptable failure. In a firm real-time system, a late result has no value, although an occasional miss may be tolerated. In a soft real-time system, late completion reduces quality of service but does not invalidate the result completely. These categories describe consequences, not merely numerical deadline values.

This chapter develops periodic and aperiodic task models, latency and jitter measures, fixed-priority rate-monotonic scheduling, dynamic-priority earliest-deadline-first scheduling, response-time analysis, priority inversion protocols, and practical timing-validation methods.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Distinguish hard, firm, and soft real-time requirements.

2. Model periodic, sporadic, and aperiodic tasks using execution time, period, deadline, and release-time parameters.

3. Explain latency, response time, and jitter and identify their sources.

4. Apply utilization tests for rate-monotonic and earliest-deadline-first scheduling.

5. Perform exact response-time analysis for fixed-priority task sets.

6. Explain priority inversion and evaluate inheritance and ceiling-based controls.

7. Select suitable scheduling and timing-analysis methods for embedded applications.

8. Critically assess the limitations of analytical guarantees in practical systems.

1. Foundations of Real-Time Behavior

1.1 Temporal correctness

For a task instance released at time r and completing at time f, its response time is:

R = f − r

where R is measured in units of time. If the task has relative deadline D, its absolute deadline is r + D, and the deadline requirement is:

R ≤ D

This basic condition must be evaluated for all relevant task instances and operating scenarios. A task can have low average response time but still violate a hard deadline because of a rare worst-case delay. Consequently, worst-case execution time (WCET) and worst-case response time are more important than average values for hard real-time certification.

Latency normally denotes the delay between an externally significant event and the beginning or completion of the corresponding service. The exact definition must be stated. For example, interrupt latency is the time from hardware assertion of an interrupt to the execution of its handler; task response latency may include release delay, preemption, execution, blocking, and communication delay.

Jitter is variation in timing. Release jitter describes variation in the time at which a task becomes ready relative to its nominal release. Completion jitter describes variation in finishing times. Sampling jitter in a control system can change the effective sampling interval and degrade stability even when every individual deadline is met.

1.2 Hard, firm, and soft real-time requirements

Hard real-time requirements arise when late completion can cause physical damage, loss of safety, or violation of a mandatory specification. Examples include airbag deployment and over-current protection. Analysis normally uses conservative bounds and must account for overload, faults, and platform interference.

Firm real-time requirements occur when a late result is useless, but occasional losses are acceptable at the system level. A missed image-processing frame may be discarded rather than delivered late. The relevant performance measure may be the proportion of useful results, provided an explicit maximum-loss policy is defined.

Soft real-time requirements tolerate lateness with graceful degradation. Examples include multimedia rendering, networked visualization, and some user-interface functions. Average response time, percentile latency, throughput, and deadline-miss ratio may be more useful than absolute guarantees, although safety-related functions within the same system still require hard analysis.

These categories should not be confused with system criticality. A soft task can execute on a platform that also contains hard tasks, but shared resources must be controlled so that the soft workload cannot compromise hard deadlines.

2. Task and Workload Models

A task is a schedulable unit of work. A useful task model defines:

• release time r: the time at which an instance becomes eligible;
• execution time C: processor time required under specified assumptions;
• relative deadline D: maximum permitted time from release to completion;
• period T: minimum or nominal interval between releases;
• priority: the rule used to select among ready tasks;
• worst-case execution time: an upper bound on C for the analyzed hardware and software configuration.

For a periodic task, instances are released at regular intervals T. A common constrained-deadline model has D ≤ T. An implicit-deadline model has D = T. A task with D > T is a arbitrary- or unconstrained-deadline task and may have multiple active instances; analysis becomes more involved.

A sporadic task has a minimum inter-arrival time T but may arrive at any time after the previous release. Sporadic models are appropriate for external events such as network packets or sensor alarms because they support conservative analysis without assuming exact periodicity. An aperiodic task has no fixed arrival pattern. It may be served by background execution, a server task, or an event-driven policy.

The utilization of a periodic task is:

U_i = C_i / T_i

where C_i and T_i use the same time units. The total utilization of n tasks is:

U = Σ(C_i / T_i), for i = 1 to n

Utilization is processor demand relative to time capacity. It is necessary for many schedulability tests, but it is not always sufficient. A task set with low utilization can still miss deadlines because of unfavorable release relationships, blocking, overhead, or deadlines shorter than periods.

2.1 Worst-case execution time

WCET is not simply the longest time observed during testing. Testing samples executions, whereas WCET analysis seeks a defensible upper bound over relevant input values, control paths, hardware states, cache behavior, pipeline effects, interrupts, and operating-system activity. Static analysis can provide conservative bounds but may be difficult for complex processors. Measurement-based methods can be tighter but require justified coverage and controlled instrumentation.

The WCET estimate should include relevant context-switch, scheduling, synchronization, and interrupt costs. If an analysis assumes C excludes these costs, the costs must be modeled separately and consistently.

2.2 Preemptive and non-preemptive execution

In a preemptive scheduler, a running task may be suspended so that another ready task executes. Preemption improves responsiveness but introduces context-switch overhead, cache disruption, and possible synchronization complexity. In a non-preemptive system, a task runs until completion or voluntary blocking. This simplifies reasoning but can cause a high-priority task to wait for a long low-priority execution segment.

Many embedded kernels use a hybrid design: most tasks are preemptive, while short critical sections or device operations are non-preemptive. The timing model must reflect the actual implementation.

3. Latency, Jitter, and Timing Budgets

A useful end-to-end timing budget decomposes delay into event detection, interrupt handling, release, scheduling, execution, communication, and actuation. For a simple chain, an upper-bound latency may be represented as:

L_total ≤ L_sensor + L_interrupt + L_release + L_queue + L_execution + L_communication + L_actuator

This is a budget decomposition rather than a universal equality. Terms must not be double-counted, and correlated or overlapping delays require careful modeling.

For a task under fixed-priority preemptive scheduling, response time commonly includes execution, interference from higher-priority tasks, and blocking from lower-priority critical sections. A task may also suffer release jitter from upstream tasks. Jitter propagates through chains: variable completion of a sensor task can produce variable release of a controller task, which can then affect actuator timing.

In control applications, deterministic bounds are often more important than mean latency. In multimedia or cloud-connected embedded devices, percentile latency and deadline-miss rate may be appropriate for soft requirements. The metric must correspond to the consequence of timing failure.

4. Scheduling Principles

A scheduler selects the next ready task. A scheduling policy may be static, such as fixed priority, or dynamic, such as earliest deadline first. It may be preemptive or non-preemptive, centralized or distributed, and work-conserving or deliberately throttled.

A schedule is feasible if every task meets its specified timing constraints under the assumed workload, execution-time bounds, resource access, and platform behavior. A task set is schedulable under a policy if the policy produces a feasible schedule for the relevant task model.

4.1 Rate-monotonic scheduling

Rate-monotonic (RM) scheduling assigns higher priority to tasks with shorter periods. It is a fixed-priority policy: priorities do not change during execution. For periodic tasks with independent execution, D_i = T_i, preemption, negligible overhead, and fixed priorities assigned according to increasing period, RM has a sufficient utilization bound:

U ≤ n(2^(1/n) − 1)

where n is the number of tasks. As n approaches infinity, the bound approaches ln 2, approximately 0.693. For two tasks, the bound is approximately 0.828.

This is a sufficient, not necessary, condition. If utilization is below the bound, the task set is guaranteed schedulable under the assumptions. If utilization is above it, the task set may still be schedulable; exact response-time analysis is then appropriate.

RM is attractive in embedded systems because priorities are stable, implementation is simple, and priority-based operating systems are widely available. Its limitations include pessimism of the utilization bound and difficulty handling arbitrary deadlines, non-independent tasks, and shared resources without extensions.

4.2 Earliest-deadline-first scheduling

Earliest-deadline first (EDF) assigns the highest priority to the ready job with the earliest absolute deadline. Priorities can change whenever jobs are released or completed. For independent, preemptive periodic tasks on a uniprocessor with D_i = T_i and negligible overhead, EDF is schedulable when:

U ≤ 1

Under the stated ideal assumptions, EDF is optimal for feasibility: if a feasible schedule exists on one processor, EDF can produce one. This does not mean EDF is always operationally superior. Dynamic priority changes, overload behavior, implementation complexity, and fault containment may favor fixed priority in safety-critical products.

For constrained deadlines D_i ≤ T_i, simple utilization equalities are not generally sufficient. Demand-bound or processor-demand analysis examines whether the cumulative execution demand of jobs with deadlines within an interval can exceed the interval length. Practical tools often perform exact or conservative demand analysis.

4.3 Aperiodic service

Aperiodic work can interfere unpredictably with periodic deadlines. Background service executes aperiodic tasks only when no more urgent periodic work is ready, providing strong isolation but possibly poor aperiodic response.

A server reserves processor capacity for aperiodic work. A polling server executes at scheduled polling times; a sporadic server replenishes consumed capacity according to a defined policy while preserving an analyzable capacity budget. Server parameters include capacity Q and replenishment period P, with nominal server utilization Q/P. Server design must account for implementation overhead and the interaction between server priority and hard periodic tasks.

5. Exact Response-Time Analysis

For fixed-priority preemptive scheduling, response-time analysis provides a stronger test than the RM utilization bound. For task i, an initial response-time recurrence is:

R_i^(k+1) = C_i + B_i + Σ over higher-priority tasks j of ceil(R_i^k / T_j) C_j

where B_i is the maximum blocking time, T_j is the minimum inter-arrival time of higher-priority task j, and C_j is its execution time. The ceiling term counts the maximum number of interfering releases during the response interval. Start with R_i^(0) = C_i + B_i and iterate until either:

1. R_i^(k+1) = R_i^(k), indicating a fixed point; or

2. R_i^(k+1) > D_i, indicating failure of the test.

The task is schedulable if the converged response time satisfies R_i ≤ D_i. The analysis assumes a single processor, known priorities, independent ready releases except for modeled blocking, and valid execution-time and arrival bounds. Release jitter, self-suspension, non-preemptive sections, multiprocessor effects, and execution-time variation require extensions.

Worked Example: Fixed-priority analysis

Consider three independent periodic tasks on one preemptive processor:

Task A: C = 1 ms, T = 4 ms, D = 4 ms.

Task B: C = 1 ms, T = 5 ms, D = 5 ms.

Task C: C = 2 ms, T = 10 ms, D = 10 ms.

RM priorities are A, B, C. Total utilization is 1/4 + 1/5 + 2/10 = 0.65. The three-task RM sufficient bound is 3(2^(1/3) − 1), approximately 0.780, so the task set passes the sufficient test.

For A, R_A = C_A = 1 ms, which meets its 4 ms deadline.

For B:

R_B^(0) = 1.

R_B^(1) = 1 + ceil(1/4)(1) = 2 ms.

R_B^(2) = 1 + ceil(2/4)(1) = 2 ms.

Thus R_B = 2 ms ≤ 5 ms.

For C:

R_C^(0) = 2.

R_C^(1) = 2 + ceil(2/4)(1) + ceil(2/5)(1) = 4 ms.

R_C^(2) = 2 + ceil(4/4)(1) + ceil(4/5)(1) = 4 ms.

Thus R_C = 4 ms ≤ 10 ms. All tasks pass the response-time test.

The example illustrates that utilization and response-time analysis answer related but different questions. Utilization summarizes average processor demand, whereas response-time analysis accounts for release interference and deadlines.

6. Priority Inversion and Resource Sharing

Priority inversion occurs when a high-priority task is delayed by a lower-priority task holding a required resource. The inversion can become unbounded if medium-priority tasks repeatedly preempt the lower-priority lock holder. This is not merely a performance issue: it can violate hard deadlines and create difficult-to-reproduce failures.

A mutex with priority inheritance temporarily raises the lock holder's priority to that of the highest-priority blocked task. When the resource is released, the holder returns to its appropriate priority. Priority inheritance limits the effect of medium-priority interference, but nested locks and chained blocking can complicate analysis.

The priority ceiling protocol assigns each resource a ceiling equal to the highest priority of any task that may use it. A task may lock a resource only when the protocol's admission condition is satisfied. Ceiling protocols can prevent deadlock and bound blocking, often to at most one critical section for a task in classical single-processor models. Exact properties depend on the specific variant and assumptions.

Best practice is to keep critical sections short, avoid blocking I/O while holding a mutex, use a consistent lock order, document resource ceilings, and include blocking terms in schedulability analysis. Lock-free or wait-free techniques may reduce blocking but introduce their own complexity, memory-ordering requirements, and verification burden.

7. Timing Analysis in Real Embedded Systems

Analytical schedulability does not guarantee system-level timing unless all significant delays are represented. A complete timing argument should consider:

• interrupt masking and interrupt nesting;
• context-switch and timer-tick overhead;
• cache, pipeline, and memory-bus interference;
• DMA and peripheral contention;
• operating-system services;
• communication-network latency and retransmission;
• clock drift and synchronization;
• startup, shutdown, and fault-recovery modes;
• thermal throttling and power-management transitions.

Measurement is essential but should complement, not replace, analysis. Instrumentation can alter timing, and observed maxima are not proofs of WCET. Trace-based validation should use representative and stress workloads, while formal or semi-formal analysis should justify the bound used for safety claims.

For distributed embedded systems, end-to-end timing analysis is required. A message may wait in a task queue, traverse a bus, be delayed by arbitration, and then wait for a receiving task. Time-triggered architectures can provide highly predictable behavior, while event-triggered architectures can offer flexibility and responsiveness. Many industrial systems combine both approaches.

8. Applied Case: Illustrative Automotive Battery Protection Controller

Background

Consider an illustrative electric-vehicle battery protection controller. It samples cell voltage and temperature, detects over-current conditions, estimates state variables, and commands contactors. The over-current protection path is hard real-time because a delayed disconnection can damage hardware. State estimation is firm real-time: a stale estimate is discarded. Diagnostic logging is soft real-time.

Problem

The controller uses a single-core microcontroller and a preemptive fixed-priority kernel. Requirements are:

• protection task: C = 0.8 ms, T = 5 ms, D = 5 ms;
• estimation task: C = 1.5 ms, T = 20 ms, D = 20 ms;
• diagnostics task: C = 2 ms, T = 100 ms, D = 100 ms;
• asynchronous communication task: bounded sporadic arrivals with minimum inter-arrival time 50 ms and C = 1 ms.

The protection task must not be delayed by unbounded diagnostic logging or a communication mutex.

Analysis and approach

The protection task receives the highest fixed priority because it has the shortest period and the greatest consequence of lateness. The estimation task receives the next priority. Diagnostics execute at lower priority. Communication is modeled as a sporadic task rather than as an unlimited aperiodic background task.

Ignoring blocking initially, utilization is:

0.8/5 + 1.5/20 + 2/100 + 1/50 = 0.16 + 0.075 + 0.02 + 0.02 = 0.275.

The low utilization is encouraging, but it is not by itself a safety argument. Suppose the protection task can be blocked by one 0.3 ms lower-priority critical section. Its response time is:

R_protection = C + B = 0.8 + 0.3 = 1.1 ms,

because no higher-priority task exists. This meets the 5 ms deadline. The critical section is nevertheless redesigned to avoid logging and peripheral waits.

The estimation task may be interfered with by the protection task. Its initial value is 1.5 ms. The next iteration is:

R^(1) = 1.5 + 0.3 + ceil(1.5/5)(0.8) = 2.6 ms.

The next iteration is:

R^(2) = 1.5 + 0.3 + ceil(2.6/5)(0.8) = 2.6 ms.

Thus its response-time bound is 2.6 ms, well below 20 ms, under the modeled assumptions. Communication and diagnostics are prevented from holding protection resources for long periods by using short bounded critical sections and priority-ceiling controls.

Outcome

The design provides a defensible initial timing argument. Verification must still measure interrupt latency, context-switch overhead, ADC and DMA behavior, bus delays, clock tolerance, and fault-handling paths. The protection task should be tested under maximum interrupt and communication load, not only during nominal operation.

Learning points

The case demonstrates that task priority should reflect both timing and consequence, asynchronous arrivals must be bounded, resource access must be included in the model, and low average utilization does not eliminate the need for worst-case analysis. It also illustrates separation between safety-critical and quality-of-service functions.

9. Limitations, Governance, and Contemporary Developments

Scheduling theory is strongest when assumptions are explicit and the platform is sufficiently deterministic. Modern processors introduce caches, speculative execution, multicore shared memory, heterogeneous cores, and complex power-management behavior. On multicore systems, tasks may migrate, shared caches may interfere, and global or partitioned scheduling choices affect analysis. Classical single-processor RM and EDF results cannot simply be applied without modification.

Virtualization and containerized embedded platforms require temporal isolation so that one partition cannot consume another's guaranteed capacity. Networked control systems require co-analysis of computation and communication. Time-sensitive networking and synchronized time bases support bounded communication latency, but configuration and fault behavior remain important.

Artificial intelligence workloads present additional challenges. Inference execution times may vary with model paths, memory traffic, accelerator contention, and thermal state. A safety-critical architecture should place AI functions behind explicit timing and safety monitors, use bounded fallback behavior, and avoid treating average accelerator throughput as a deadline guarantee.

Governance requires traceable timing requirements, documented assumptions, configuration control, independent review, and evidence that the implemented system matches the analyzed system. Relevant safety frameworks vary by domain, such as automotive, aviation, medical, rail, and industrial control. Compliance is not achieved by quoting a scheduling algorithm; it requires a complete lifecycle argument covering requirements, design, implementation, verification, change management, and operation.

Best-Practice Design Procedure

1. Classify each function by consequence of lateness.

2. Define release, execution, deadline, period, and inter-arrival assumptions.

3. Establish defensible WCET and blocking bounds.

4. Choose preemptive, non-preemptive, fixed-priority, or dynamic-priority scheduling deliberately.

5. Apply a quick utilization test, followed by exact response-time or demand analysis where required.

6. Bound aperiodic and sporadic traffic using servers or explicit arrival constraints.

7. Apply priority inheritance or ceiling protocols to shared resources.

8. Include operating-system, interrupt, communication, and hardware interference costs.

9. Validate with tracing and stress testing, while preserving analytical evidence.

10. Re-analyze after changes to code, compiler, hardware, clock configuration, or workload.

Chapter Summary

Real-time systems require both functional and temporal correctness. Hard real-time tasks require guaranteed deadlines; firm tasks lose value when late; soft tasks degrade in quality when delayed. Periodic, sporadic, and aperiodic task models provide different assumptions about workload arrivals. Utilization captures processor demand, while response-time and demand analyses capture interference, blocking, and deadline behavior.

Rate-monotonic scheduling assigns fixed priorities according to task periods and provides a conservative utilization bound. Earliest-deadline-first uses dynamic priorities and, under ideal uniprocessor implicit-deadline assumptions, can schedule task sets up to full utilization. Exact fixed-priority response-time analysis is essential when utilization tests are inconclusive or when blocking and deadlines must be considered explicitly.

Latency and jitter must be defined in system context and analyzed across complete processing chains. Priority inversion is controlled through priority inheritance or ceiling protocols, supported by short critical sections and disciplined resource design. Finally, analytical guarantees must be reconciled with hardware effects, communication, operating-system overhead, fault modes, and contemporary multicore or AI-based platforms.

Key Terms

Real-time system: A system whose correctness depends on logical and temporal behavior.

Hard real-time: A timing regime in which deadline violation is unacceptable or potentially hazardous.

Firm real-time: A regime in which late results have no value, although some misses may be tolerated.

Soft real-time: A regime in which lateness degrades performance or quality of service.

Release time: The time at which a task instance becomes ready for execution.

Execution time: Processor time required by a task instance under stated conditions.

WCET: A defensible upper bound on execution time.

Relative deadline: Maximum permitted time from release to completion.

Period: Nominal or minimum interval between task releases.

Sporadic task: A task with a specified minimum inter-arrival time.

Aperiodic task: A task with no fixed periodic arrival pattern.

Response time: Time between task release and task completion.

Latency: Delay between an event and a specified service point.

Jitter: Variation in release, response, or completion timing.

Utilization: Fraction of processor capacity demanded by a task set.

Rate-monotonic scheduling: Fixed-priority scheduling that gives higher priority to shorter-period tasks.

Earliest-deadline-first: Dynamic-priority scheduling that favors the ready job with the earliest absolute deadline.

Priority inversion: Delay of a higher-priority task by lower-priority resource holding or interference.

Priority inheritance: A protocol that temporarily raises a resource holder to a blocked task’s priority.

Priority ceiling: A resource-control method based on the highest priority of tasks that may use the resource.

Review Questions

Short Answer Questions

1. Distinguish hard, firm, and soft real-time requirements.

2. Define response time and explain how it differs from latency.

3. What information is specified by a periodic task model?

4. Why is WCET more important than average execution time for hard real-time analysis?

5. What is priority inversion?

Long Answer Questions

1. Explain the assumptions and limitations of rate-monotonic scheduling.

2. Compare rate-monotonic scheduling with earliest-deadline-first scheduling.

3. Derive and explain the fixed-priority response-time recurrence.

4. Discuss how jitter propagates through a sensor-processing-actuator chain.

5. Explain priority inheritance and priority ceiling protocols, including their practical trade-offs.

Analytical / Application Questions

1. For tasks with (C,T,D) values (1, 4, 4), (1, 5, 5), and (2, 10, 10) ms, calculate total utilization and determine response times under RM.

2. Design a scheduling strategy for a controller containing one hard periodic task, one firm estimation task, and one soft diagnostic task. Justify treatment of asynchronous events.

3. A low-priority logging task holds a mutex needed by a high-priority protection task while a medium-priority task is ready. Explain the resulting delay and propose a bounded solution.

Multiple Choice Questions with Answers

Question 1

Which statement best characterizes a hard real-time task?

A. Its average response time must be low.

B. A missed deadline can be unacceptable or hazardous.

C. Late results remain fully useful.

D. It has no specified deadline.

Correct Answer: B. A missed deadline can be unacceptable or hazardous.

Question 2

For a periodic task with C = 2 ms and T = 10 ms, what is its utilization?

A. 0.02

B. 0.10

C. 0.20

D. 5.00

Correct Answer: C. 0.20

Question 3

Which priority rule is used by rate-monotonic scheduling?

A. Shortest execution time receives highest priority.

B. Longest deadline receives highest priority.

C. Shortest period receives highest priority.

D. Latest release receives highest priority.

Correct Answer: C. Shortest period receives highest priority.

Question 4

Under ideal uniprocessor assumptions with implicit deadlines, EDF can schedule a periodic task set when:

A. Utilization is at most 0.50.

B. Utilization is at most the RM bound only.

C. Utilization is at most 1.

D. Every task has the same period.

Correct Answer: C. Utilization is at most 1.

Question 5

In fixed-priority response-time analysis, the ceiling term ceil(R_i/T_j) represents:

A. The number of possible interfering releases of task j.

B. The number of processors assigned to task i.

C. The task’s blocking duration.

D. The context-switch cost only.

Correct Answer: A. The number of possible interfering releases of task j.

Question 6

For three tasks, the RM sufficient utilization bound is approximately:

A. 0.500

B. 0.693

C. 0.780

D. 1.000

Correct Answer: C. 0.780

Question 7

What is the principal purpose of priority inheritance?

A. To eliminate all preemption.

B. To raise a resource holder’s priority when a higher-priority task is blocked.

C. To make all tasks execute at equal priority.

D. To increase task execution time deliberately.

Correct Answer: B. To raise a resource holder’s priority when a higher-priority task is blocked.

Question 8

A sporadic task is defined primarily by its:

A. Exact release times known forever in advance.

B. Minimum inter-arrival time.

C. Absence of any deadline.

D. Requirement to run only during idle time.

Correct Answer: B. Minimum inter-arrival time.

Question 9

If a task has C = 0.8 ms and blocking B = 0.3 ms and has no higher-priority interference, its response-time bound is:

A. 0.24 ms

B. 0.5 ms

C. 0.8 ms

D. 1.1 ms

Correct Answer: D. 1.1 ms

Question 10

Which practice most directly reduces priority-inversion duration?

A. Holding mutexes during blocking I/O.

B. Making critical sections short and bounded.

C. Allowing unlimited aperiodic arrivals.

D. Ignoring lower-priority resource users.

Correct Answer: B. Making critical sections short and bounded.