Choosing among runnable activities

When more activities are ready than processors can execute, the system must choose who runs next. Scheduling policy makes that choice, and context-switch mechanisms enact it. Activities blocked on input are not simply additional ready competitors, so increasing the total task count and increasing runnable work can have different consequences for the system.

References: [1]

Objectives shape the policy

Interactive work values response time, batch work values throughput and turnaround, and shared systems also consider fairness. First-come ordering, time slicing, and priorities make different tradeoffs. Evaluating a policy requires a stated workload and objective rather than assuming that the earliest completion of one selected job means the best overall performance.

References: [2]

Time slices and preemption

Preemption lets a system pause an activity before it voluntarily finishes. Shorter slices allow more frequent turns but increase switching overhead; longer ones can delay interactive work. Real systems also use priorities and processor affinity, extending beyond a simple teaching queue to account for the cost and constraints of actual execution environments.

References: [1]

Waiting and resource contention

A high-priority activity can wait for a lock held by lower-priority work, creating priority inversion. Raising a priority does not make a required resource immediately available. Scheduling must therefore be analyzed alongside synchronization, input-output behavior, and admission limits to explain the responsiveness and completion times that applications actually experience.

References: [2]