Time-sharing¶
Sharing finite processor time by alternating execution intervals among runnable tasks or users.
Core Idea¶
Computing time-sharing divides a finite processor's service into alternating periods assigned to multiple runnable tasks or users. A scheduler chooses what runs next, and saved context lets the displaced task continue later. A person at a terminal can therefore receive frequent responses even though, on a single execution unit, the machine is executing only one instruction stream at a time. The identity is alternating, state-preserving use of CPU time—not merely common ownership of hardware.
MIT's Compatible Time-Sharing System provided a concrete early multi-user interactive implementation. Linux documentation describes a modern scheduler tick supporting approximate task time slices, subject to scheduling class and priority. The two implementations differ in policy and hardware, but both preserve the limited-resource, temporal-assignment and resumption relation. Multicore parallelism may coexist with time-sharing without being identical to it.
Structural Signature¶
Sig role-phrases:
- Limited processor — CPU service capacity cannot satisfy every ready task at the same instant on one execution unit. It is constitutive. Counterfactual: A dedicated processor per task is parallel allocation, not time-sliced sharing.
- Competing runnable work — Several tasks or users have work eligible for that capacity. It is constitutive. Counterfactual: One sole task on an idle machine does not present shared execution demand.
- Temporal assignment policy — The system selects alternating intervals, often with priorities or slices. It is constitutive. Counterfactual: A queue that runs one job to completion before starting the next is batch service, not this responsive alternation.
- Context preservation — Task state survives interruption and resumption. It is constitutive. Counterfactual: Restarting a job from scratch each turn is not coherent concurrent progress.
- Observed service — Each task or user gains periodic progress within the selected responsiveness/fairness regime. It is central. Counterfactual: The apparent concurrency is not literal simultaneous execution on a single core.
What It Is Not¶
- Not literal single-core simultaneity. Alternating execution produces apparent overlap.
- Not just batch processing. A run-to-completion queue lacks the alternating service relation.
- Not multicore parallelism. Separate cores can run tasks simultaneously rather than time-slice one core.
- Not storage sharing. The constrained resource here is processor execution time.
- Closest near-miss. An offline batch queue that runs each program to completion on the same computer shares hardware across jobs, but does not give them interleaved time slices or concurrent interactive progress.
Scope of Application¶
- Operating systems. Schedule runnable tasks on processors.
- Interactive computing. Support responsive access from several users.
- Resource management. Compare priorities, fairness and throughput.
- Computing history. Distinguish CTSS-style service from earlier batch use.
Clarity¶
A time-sharing scheduler repeatedly gives a CPU to one runnable task, preserves its state, then switches to another. CTSS used the idea for multiple interactive users; Linux documents approximate CPU slices among tasks. On a single execution unit this is rapid alternation, not simultaneous execution, and a batch queue that finishes one job before the next is not the same mechanism.
Manages Complexity¶
The slice length and dispatch policy affect response, fairness and overhead. A task may block for I/O or be governed by a special scheduling class, so no one uniform fixed quantum describes every implementation. Multicore machines can combine actual parallel execution across cores with time-sharing on each core. State preservation is necessary for coherent continuation.
Abstract Reasoning¶
- Identify the bounded processor and plural runnable tasks.
- Choose a temporal allocation or scheduling policy.
- Grant a task an execution interval.
- Save its context when interrupted or blocked.
- Dispatch another task and later resume the first.
- Evaluate response, fairness and switching overhead under the actual policy.
Knowledge Transfer¶
Temporal sharing of a finite resource appears in communications and infrastructure, but computing time-sharing specifically alternates CPU execution among task contexts. A radio time-division channel or shared classroom schedule is structurally analogous without being an operating-system instance.
Examples¶
Canonical¶
MIT's 1963 CTSS programmer guide describes an operating multi-user interactive service on a shared mainframe. Foreground terminal users submit commands while the supervisor controls execution and returns the machine to other runnable work. Its defining insight is that one processor is assigned in alternating intervals without discarding each user's program state; CTSS is a real historical system, not a claim that every modern OS copied its exact policy.
Mapped back: Limited processor → CTSS mainframe CPU; Competing runnable work → multiple foreground terminal users' programs; Temporal assignment policy → supervisor dispatch of users' execution intervals; Context preservation → per-user program and execution state retained between turns; Observed service → interactive terminal responsiveness across users.
Applied / In Practice¶
The Linux kernel's own administration documentation explains its scheduler tick as a means of CPU time-sharing: a runnable task receives an approximate slice, then the scheduler may switch to another task, conditional on scheduling class and priority. This is a documented ongoing implementation mechanism rather than a claim that all Linux classes use one fixed round-robin quantum.
Mapped back: Limited processor → logical CPU whose execution time is allocated; Competing runnable work → tasks on its run queue; Temporal assignment policy → scheduler tick, classes and priority affecting turns; Context preservation → task switch resumes the next runnable task's state; Observed service → multiple tasks make progress over wall-clock time.
Structural Tensions¶
T1 — Short Slices versus Switching Overhead. Frequent switches improve apparent response but spend more work on bookkeeping rather than user computation.
Diagnostic: What slice scale suits the workload?
T2 — Fairness versus Priority. Equal turns can protect ordinary users while priority classes reserve more service for urgent tasks.
Diagnostic: Which policy governs competing claims?
T3 — Interactive Response versus Throughput. Keeping terminals responsive may trade off against long-run batch efficiency.
Diagnostic: Which observable is being optimized?
Structural–Framed Character¶
The approved DAG parent is Allocation: a scheduler assigns finite CPU execution to competing runnable tasks under a policy. Time-sharing adds alternating intervals and preserved task context, enabling user-visible overlap without implying simultaneous execution on one core.
Evaluative weight: Fairness and responsiveness are policy aims, not guaranteed properties. Human-practice-bound: Moderate, because scheduler criteria are designed while finite processor capacity is physical. Institutional origin: Operating-system practice established the term; no vendor is necessary. Vocabulary travels: Temporal sharing occurs in radio or classrooms, but computing time-sharing requires CPU task contexts. Import versus recognize: One recognizes the mechanism through alternating service and saved state; calling multiple-core parallelism time-sharing imports a single-resource scheduling relation.
Its character: A computing-specific allocation mechanism with a portable turn-taking skeleton and a processor-context boundary.
Structural Core vs. Domain Accent¶
Skeletal core. A bounded resource is assigned to competing claimants in temporal turns. Domain-bound accent. CPU execution, scheduler policy and saved task context define computing time-sharing. Transfer boundary. Mere common ownership or parallel separate processors does not instantiate this alternating single-resource mechanism.
Instantiates / Related Primes¶
This entry is a kind of Allocation.
-
Parent: Allocation. Finite processor time is assigned among competing runnable claimants under a scheduling criterion.
-
Related: Scheduling. A dispatch policy selects the temporal turns; the current prime's more specific optimization language is not needed to assert the basic resource-assignment parent.
Relationships to Other Abstractions¶
Current abstraction Time-sharing Domain-specific
Parents (1) — more general patterns this builds on
-
Time-sharing is a kind of Allocation Prime
CPU time slices assign finite processor service among competing runnable tasks.The current Allocation prime requires limited supply, competing claimants, a feasibility bound, an assignment mapping and a criterion. Computing time-sharing occupies all five: CPU execution time is finite, runnable tasks compete, only bounded execution can be assigned per interval, a scheduler maps tasks to slices, and its policy supplies fairness or priority criteria. Every time-sharing instance thus performs resource allocation, while generic allocation does not require task contexts, CPU execution or temporal alternation. Child-to-parent strict subsumption is valid without claiming every scheduler optimizes an explicit objective.
Hierarchy path (1) — routes to 1 parentless root
- Time-sharing → Allocation → Scarcity → Constraint
Neighborhood in Abstraction Space¶
Time-sharing sits in a crowded region of the domain-specific corpus (33rd percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.
Family — Queueing, Networks & Concurrent Systems (9 abstractions)
Nearest neighbors
- Service-Oriented Programming — 0.91
- Layered Queueing Network — 0.90
- Urgent Computing — 0.88
- Reachability analysis — 0.87
- Optimizing Compiler — 0.87
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
- Batch processing. Tell: May share one computer across jobs but runs them to completion rather than interleaving interactive turns.
- Multicore parallelism. Tell: Runs on separate execution units simultaneously.
- Multitasking. Tell: Outcome of multiple tasks progressing, which can be achieved by several mechanisms.
- Time-division multiplexing of a network. Tell: Alternates channel capacity, not processor task contexts.
References¶
- MIT Computation Center, The Compatible Time-Sharing System: A Programmer's Guide (1963): primary documentation of an operating multi-user interactive system and supervisor-controlled service. Its manual notes that some features described were still planned, so only the documented operating core is used here.
- Linux Kernel Documentation, CPU Idle Time Management: official scheduler-tick explanation of approximate task time-slice sharing, qualified by class and priority; not a universal fixed-quantum policy.