Concurrent background work needs priority, not first-come-first-served

What it is

Several background jobs at once share one pool of bandwidth, CPU, battery. First-come-first-served (FIFO) lets a two-hour backup block a thirty-second “send this image”. Priority scheduling lines up what the person needs more in this moment: small, interaction-dependent, just submitted, may cut in front of large and deferrable. Without priority, concurrency only turns “one after another” into “everyone inches together”, and the urgent one is no faster.

This leaf is scheduling policy. Whether the list can be manually reordered is a human override; here the system itself must not treat queue position as importance.

Why it happens

The executor sees a stream of tasks; the person sees “which one I am waiting on now”. Waiting cost is not uniform: sending this image blocks a conversation; a backup blocks the night. FIFO treats arrival time as importance, impersonating the goal with submit order. Resources are also exclusive: uplink filled by the backup turns a thirty-second upload into “wait for a gap in the backup”. Priority splits tasks into at least two bands — interaction-critical and deferrable — and lets the high band preempt or interleave. Preemption must keep the low band’s breakpoint, or priority becomes a durability wrecker.

Default priority should also be inferable: work on the object the user is looking at in the foreground, small volume, a near deadline, above a silent full-library scan. A wrong inference is more annoying than FIFO, so defaults stay conservative: pull obvious interaction-critical work forward, do not run a hidden scorer people cannot predict.

Where it stops holding

One task: priority is meaningless. All tasks equally urgent (ten identical report exports) — FIFO is predictable; forced scoring feels like queue-jumping. A live constraint (a streaming push) is not priority, it is exclusive resource; other background should yield to pause, not “a little higher”. The OS’s own jobs (system backup, app update) compete with the product; in-product priority cannot command the OS, but can demote deferrable work when the system is busy, so both sides do not grab. On low battery every deferrable should drop to stop, leaving only interaction-critical — priority flipping with situation, not cancelling priority.

Applying it

• At least two bands: what the user is waiting on (send, export the open file) above deferrable (full backup, prefetch). High may interleave; low, when preempted, continues from a breakpoint.
• Do not sort only by submit time. FIFO is fine inside a band, not across bands.
• The job being waited on should look, in state, as if it is occupying resource, so people do not read stuck.
• How to check: submit a long backup, thirty seconds later submit sending an image. The send should finish while the backup is still running. If the send sits behind the backup for a full two hours, that is FIFO. Then open, in the foreground, a document being exported: that export should outrank a background prefetch submitted at the same moment.

Related

• Same group: I3.12.1 Long tasks must survive quit and reboot · I3.12.3 Submitted background work must be reorderable or cancellable · I3.12.4 Background resource use must be visible, or it looks like a leak
• Nearby: I3.07 Background tasks · I1.03 Attention-holding ceiling
• Search terms: job priority · FIFO · preemption