By the early 1960s, multiprogramming had solved the CPU utilization problem—computers hummed along at 80% utilization or better. But a growing chorus of computer scientists pointed out a critical flaw: the human programmer was terribly underutilized.

Consider the programmer's experience: Write code on paper. Punch it onto cards. Submit the deck. Wait hours (sometimes overnight) for output. Discover a typo. Fix the card. Submit again. Wait again. A simple debugging session that might take 30 minutes on a modern computer consumed days of real time.

This wasn't just frustrating—it was economically wasteful. Programmers' salaries were rising, and their time was expensive too. What if, instead of maximizing computer utilization, we maximized programmer productivity?

The term 'time-sharing' was coined by John McCarthy at MIT in 1959. The vision was radical: share the computer's time among multiple interactive users, giving each the illusion of having the entire machine to themselves.

McCarthy and other pioneers recognized that human computer use was inherently 'bursty'. A programmer types a command, then pauses to think. Types another line, pauses again. In the seconds between keystrokes, an entire batch job could complete! Why not use those intervals to serve other users?

The Time-Sharing Philosophy:

What Made Time-Sharing Different:

1. Interactive Terminals: Instead of punched cards, users sat at typewriter-like terminals connected to the computer. They could type commands and see responses immediately.

2. Short Time Slices: The OS rapidly switched between users—every 100 milliseconds or so—giving each a 'turn' at the CPU. Users couldn't perceive these switches.

3. Response Time Focus: The OS was designed to keep response time under about 1 second for simple operations. Users needed to feel the computer was responsive.

4. Conversational Interaction: Programs could prompt for input, wait for the user's response, then continue—a style of interaction impossible with batch processing.

Multiprogramming used non-preemptive scheduling—jobs ran until they voluntarily gave up the CPU (typically by initiating I/O). This was fine for batch jobs that alternated between compute and I/O phases.

But time-sharing couldn't work this way. Consider a compute-bound scientific job that performs millions of calculations without any I/O. Under non-preemptive scheduling, this job would monopolize the CPU indefinitely—all interactive users would freeze.

The Solution: Preemptive Scheduling

Time-sharing systems introduced preemption—the OS forcibly takes the CPU from a running process, even if that process hasn't finished or blocked. This required new hardware support:

The Time Quantum:

The timer was set to fire after a fixed interval called the time quantum (also called time slice). Typical values were 100-500 milliseconds. When the quantum expired:

Timer Interrupt Fires
        ↓
Hardware saves PC, switches to kernel mode
        ↓
Timer ISR (Interrupt Service Routine) executes
        ↓
OS saves full process state to PCB
        ↓
OS selects next process (scheduling decision)
        ↓
OS loads new process's state from PCB
        ↓
OS sets timer for new quantum
        ↓
OS returns to user mode, new process resumes

Choosing the Quantum:

The quantum length involved tradeoffs:

Round Robin Scheduling:

The classic time-sharing scheduling algorithm was Round Robin (RR): processes were arranged in a circular queue, each receiving one quantum before the next. This guaranteed:

• Fairness: Every process got equal CPU time
• Bounded Wait: Maximum wait = (n-1) × quantum for n processes
• Simplicity: No priority calculations, just take turns

    Process Queue (circular):
    
    ┌───────────────────────────────────────────┐
    │                                           │
    ▼                                           │
┌───────┐   ┌───────┐   ┌───────┐   ┌───────┐  │
│  P1   │──▶│  P2   │──▶│  P3   │──▶│  P4   │──┘
└───────┘   └───────┘   └───────┘   └───────┘
    ▲
    │
  Currently
  Running

After P1's quantum expires, P2 runs, then P3, then P4, then back to P1. Each user's terminal feels responsive because their process runs every few hundred milliseconds.

Time-sharing dramatically increased the number of simultaneous users—from a handful of batch jobs to dozens or even hundreds of interactive sessions. Memory became the critical bottleneck.

Consider: each interactive user needs a text editor, command interpreter, and any programs they're running. With 50 users, that's 50 copies of the editor, 50 copies of the command interpreter... Memory requirements exploded.

Virtual Memory emerged as the solution—one of the most important innovations in computing history. The core idea: give each process the illusion of having vast, private memory, while the OS transparently manages where data actually lives (RAM or disk).

The Address Translation Hardware:

Virtual memory required substantial hardware support—the Memory Management Unit (MMU):

         Virtual Address (from CPU)
                    │
                    ▼
    ┌───────────────────────────────────────┐
    │            Virtual Address            │
    │  ┌─────────────────┬────────────────┐ │
    │  │   Page Number   │  Offset        │ │
    │  │    (20 bits)    │  (12 bits)     │ │
    │  └────────┬────────┴───────┬────────┘ │
    └───────────┼────────────────┼──────────┘
                │                │
         ┌──────▼──────┐         │
         │ Page Table  │         │
         │   Lookup    │         │
         │             │         │
         │ VPage → PFrame       │
         └──────┬──────┘         │
                │                │
                ▼                │
    ┌────────────────────────────▼──────────┐
    │           Physical Address            │
    │  ┌─────────────────┬────────────────┐ │
    │  │  Frame Number   │    Offset      │ │
    │  │    (20 bits)    │   (12 bits)    │ │
    │  └─────────────────┴────────────────┘ │
    └───────────────────────────────────────┘
                    │
                    ▼
              Physical RAM

For a 4KB page size (12-bit offset), a 32-bit virtual address has 20 bits for the page number. The page table translates this to a physical frame number, which is combined with the unchanged offset to produce the physical address.

Benefits for Time-Sharing:

Virtual memory solved multiple time-sharing challenges:

1. More Users: Inactive pages could be swapped to disk, freeing RAM for active users
2. Isolation: Each process's address space was completely isolated—security and stability
3. Sharing: Common code (like text editors) could be shared: one physical copy, mapped into many address spaces
4. Simplified Programming: Programmers didn't need to know where their program loaded—always address 0
5. Large Programs: A process's virtual address space could exceed physical RAM

Time-sharing systems introduced a fundamentally new I/O pattern: interactive terminal I/O. Unlike batch processing where entire jobs were read from cards and entire outputs written to printers, interactive systems had to handle character-by-character input from potentially dozens of simultaneous users.

The Terminal:

Early terminals were typewriter-like devices (Teletypes or 'TTYs') that printed output on paper and sent input character-by-character as the user typed. Each keystroke generated an interrupt to the computer.

  Terminal (TTY)
  ┌─────────────────────────────────────────┐
  │  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ (paper output) │
  │  $ ls -la                               │
  │  total 48                               │
  │  drwxr-xr-x  5 user  ...               │
  │  $ _                    (cursor)        │
  ├─────────────────────────────────────────┤
  │  [keyboard]                             │
  └─────────────────────────────────────────┘
           │
           │ Serial line (RS-232)
           │ ~110 baud (characters/sec)
           ▼
  ┌─────────────────────────────────────────┐
  │           Computer                       │
  │   ┌───────────────────────────────────┐ │
  │   │ Terminal Multiplexer (hardware)   │ │
  │   │ • Buffers input/output            │ │
  │   │ • Generates interrupts            │ │
  │   │ • Handles multiple lines          │ │
  │   └───────────────────────────────────┘ │
  └─────────────────────────────────────────┘

Line Discipline:

The OS implemented a line discipline (or 'line driver')—a software layer that processed terminal I/O between raw hardware and applications:

  Application
       │
       │ read()/write() - whole lines
       ▼
  ┌─────────────────────────────────────────┐
  │           Line Discipline               │
  │  • Buffers input until newline          │
  │  • Handles editing (backspace, etc.)    │
  │  • Echoes characters back               │
  │  • Interprets control characters        │
  │  • Handles flow control (^S/^Q)         │
  └─────────────────────────────────────────┘
       │
       │ Character at a time
       ▼
  Terminal Driver (hardware interface)
       │
       ▼
  Physical Terminal

The line discipline accumulated characters until the user pressed Enter, then delivered the complete line to the application. This meant applications didn't need to handle every keystroke—just complete commands.

Several systems pioneered time-sharing and shaped all subsequent interactive computing. Their innovations remain visible in modern operating systems.

CTSS - Compatible Time-Sharing System (MIT, 1961):

CTSS was the first general-purpose time-sharing system. Developed at MIT's Computation Center, it demonstrated that time-sharing was practical:

Multics - Multiplexed Information and Computing Service (1965-1969):

Multics was the most ambitious computing project of the 1960s—a collaboration between MIT, Bell Labs, and GE to build the definitive time-sharing system:

TSS/360 - Time Sharing System/360 (IBM, 1966-1971):

IBM's attempt to add time-sharing to its System/360 line was troubled but influential. It demonstrated the difficulty of retrofitting time-sharing onto batch-oriented hardware.

TOPS-10/TENEX (DEC, 1970s):

Digital Equipment Corporation's time-sharing systems for the PDP-10 mainframe became wildly popular in universities and research labs. TENEX introduced many innovations later adopted by Unix and others:

• Demand paging implementation
• Superior file naming
• Command completion (ancestor of tab-completion)

Time-sharing systems needed a new interface between user and machine. Batch systems used JCL—rigid, formal, processed by operators. Interactive systems needed something a human could type and see responses to in real-time.

The Shell emerged as this interface: a program that reads user commands, interprets them, and executes appropriate actions. It's called a 'shell' because it wraps around the kernel, providing the outer layer users interact with.

Shell Responsibilities:

The Interactive Loop:

A shell operates in a simple loop—the Read-Eval-Print Loop (REPL):

while (true) {
    print prompt ("$ ");
    line = read_line();
    tokens = parse(line);
    if (is_builtin(tokens[0])) {
        execute_builtin(tokens);
    } else {
        pid = fork();
        if (pid == 0) {  // child
            exec(tokens[0], tokens);
        } else {  // parent
            wait(pid);
        }
    }
}

This simple structure—read command, fork child, execute program, wait for completion—remains the fundamental model of Unix shells today.

Pipes: The Killer Feature:

Perhaps the most powerful shell concept was the pipe—connecting the output of one program to the input of another:

cat log.txt | grep ERROR | wc -l

This command reads a log file, filters for lines containing 'ERROR', and counts them—three simple programs combined to solve a complex task. The shell creates pipes between processes automatically.

The philosophy this enabled—small, focused programs that do one thing well, combined through pipes—became the 'Unix philosophy' and influenced software design for decades.

Time-sharing fundamentally changed how humans relate to computers. It established patterns that remain foundational today:

Cloud Computing: Time-Sharing Reborn:

The parallels between 1960s time-sharing and modern cloud computing are striking:

Time-sharing systems marked the transition from batch-oriented, machine-centric computing to interactive, human-centric computing. This revolution introduced concepts and technologies that remain fundamental today:

What's Next:

While time-sharing flourished on large, expensive mainframes and minicomputers, a revolution was brewing. Advances in chip technology would soon make it possible to put a computer on a desk—and eventually in a pocket. The next page explores the personal computer revolution and how it democratized computing.