Tensions in Practice: Short-request response in tension with uninterrupted execution¶
Single worker · an arriving short request
A long computation A is already using a worker when short request B arrives. Letting A finish keeps its execution uninterrupted, but B waits. Preempting A lets B run sooner, while requiring A’s state to be saved and restored and delaying its completion. This changes work already in progress, not merely the order of jobs still waiting to start.
Respond to arriving short work
Give a newly arrived short request service before the current long operation completes.
Preserve a predictable uninterrupted run
Avoid extra interruptions and execution-state handoffs in the work already running.
Why these aims pull against each other
One worker cannot serve both jobs at once. Moving B into the middle of A’s execution transfers waiting and adds scheduling work rather than creating capacity.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Finish A first
Keep A running to completion, then serve B.
- What it protects
- A avoids this interruption and the associated state-switching work.
- What it costs
- B’s response waits for all of A’s remaining service.
- When it fits
- Fits acceptable arrival waiting, bounded running operations, or work that cannot be safely suspended at the requested point.
Illustration note: The example assumes B is next after A and no additional arrivals. Uninterrupted execution alone does not prove a completion deadline.
Interrupt A for B
Suspend A at a supported point, preserve its state, run B, then restore and complete A.
- What it protects
- B can receive service before A would have completed without interruption.
- What it costs
- State switching adds overhead and makes A’s completion depend on intervening scheduling decisions.
- When it fits
- Fits a safely preemptible operation and a workload where shorter response for B justifies interrupting A.
Illustration note: The illustrated finite schedule resumes A immediately after B. Repeated later arrivals would need a separate rule to prevent indefinite postponement.
What this illustration does—and does not—establish
Concurrency: Responsiveness vs Latency Predictability supplies responsiveness versus scheduling overhead. The graph makes the interrupted execution state explicit without importing the source’s broad claims about entire real-time domains.
- The comparison uses one worker; concurrency through interleaving is not simultaneous execution on extra processors.
- Job sizes are qualitative and no deadlines, measured latency or universal scheduling optimum are claimed.
- Shared-resource locks and non-preemptible sections may constrain where interruption is possible.
Source entries
Concurrency
Concurrency: Responsiveness vs Latency Predictability supplies the conflict examined here.
Responsiveness vs Latency Predictability
Concurrent systems can preempt long-running operations and service short requests quickly (good responsiveness), but preemption adds scheduling overhead and makes latency unpredictable (bad for real-time systems).