Disabling Interrupts for Mutual Exclusion

Before sophisticated synchronization primitives like semaphores, mutexes, and modern atomic operations existed, operating system designers faced a fundamental challenge: how do you ensure that a sequence of instructions executes without interruption?

This question lies at the heart of concurrent programming. When multiple processes or threads compete for shared resources, the operating system's ability to context switch at any moment creates the possibility of race conditions, data corruption, and system instability. The most direct solution—disabling the very mechanism that enables context switches—emerged as one of the earliest approaches to achieving mutual exclusion.

Disabling interrupts represents the brute-force approach to synchronization: if you prevent the CPU from responding to any external events, you guarantee that your critical section will execute atomically. No timer interrupt means no preemption. No I/O interrupt means no device-triggered scheduling. The processor becomes a single-minded execution engine, focused exclusively on completing your code.

To understand the interrupt disable approach, we must first deeply comprehend what interrupts are and why they exist. An interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention.

The Hardware Interrupt Mechanism:

Modern processors are designed around an asynchronous event model. While the CPU executes instructions sequentially, external devices—keyboards, network cards, disk controllers, timers—operate independently and at their own pace. When these devices need CPU attention, they assert an electrical signal on a dedicated interrupt line connected to the processor.

The CPU, upon completing its current instruction, checks the interrupt line. If an interrupt is pending and interrupts are enabled, the processor:

1. Saves the current execution context (program counter, status register, key registers)
2. Identifies the interrupt source through an interrupt descriptor table
3. Transfers control to the appropriate interrupt handler
4. Executes the interrupt service routine
5. Restores the previous context and resumes execution

This mechanism enables preemptive multitasking. The timer interrupt, typically firing 100-1000 times per second on modern systems, allows the operating system to regain control at regular intervals and decide which process should run next.

The Interrupt Flag: Hardware-Level Control

Processors provide a status register (also called flags register or processor status word) containing individual bits that control processor behavior. Among these is the interrupt enable flag (IF on x86 architectures, or equivalent on other processors).

• IF = 1: Interrupts are enabled; the processor will respond to hardware interrupt requests
• IF = 0: Interrupts are disabled; hardware interrupt requests are held pending

This single bit is the key to the interrupt disable approach. By clearing this bit, we tell the processor: "Do not respond to any maskable hardware interrupts until I say otherwise."

The interrupt disable approach to mutual exclusion is elegantly simple in concept:

1. Disable interrupts before entering the critical section
2. Execute the critical section with guaranteed atomicity
3. Re-enable interrupts after exiting the critical section

This guarantees that while a process is in its critical section, no context switch can occur. The timer interrupt that would trigger the scheduler is ignored. The process runs to completion within the critical section before any other process can execute.

The Hardware Instructions:

Different processor architectures provide different instructions for interrupt control. Here's how the major architectures handle it:

Correct Usage Pattern: Save and Restore

A critical subtlety in the interrupt disable approach is proper handling of nested calls. Consider the following problematic scenario:

function_a():
    disable_interrupts()       // Interrupts now OFF
    critical_work_a()
    call function_b()          // function_b also needs protection
        disable_interrupts()   // Already off, but that's fine
        critical_work_b()
        enable_interrupts()    // PROBLEM: Re-enables interrupts!
    // Interrupts are now ON, but function_a hasn't finished!
    more_critical_work_a()     // This is no longer protected!
    enable_interrupts()

The correct pattern is to save the current interrupt state before disabling and restore that saved state when done. This handles nesting correctly:

function_a():
    saved_state_a = save_and_disable()   // Save: OFF or ON
    critical_work_a()
    call function_b()
        saved_state_b = save_and_disable()  // Save: OFF (it's currently off)
        critical_work_b()
        restore(saved_state_b)              // Restore: OFF (stays off)
    more_critical_work_a()                  // Still protected!
    restore(saved_state_a)                  // Restore original state

To understand why disabling interrupts provides mutual exclusion, we must trace through the execution precisely:

The Preemption Chain:

1. A hardware timer generates an interrupt signal every N milliseconds
2. The CPU checks for pending interrupts after each instruction
3. If the interrupt flag is set, the CPU invokes the timer interrupt handler
4. The timer interrupt handler invokes the operating system's scheduler
5. The scheduler may switch to a different process
6. The previous process's critical section is suspended mid-execution

Breaking the Chain:

When we execute the cli instruction (or equivalent), we set IF = 0. Now:

1. The hardware timer still generates interrupt signals
2. The CPU still checks for pending interrupts after each instruction
3. The CPU ignores the pending interrupt because IF = 0
4. No timer interrupt handler is invoked
5. No scheduler runs
6. No context switch can occur

The critical section runs to completion with absolute certainty. This is the strongest possible guarantee—the mechanism operates at the hardware level, not through software conventions or cooperation between threads.

Formal Proof of Mutual Exclusion:

We can formally prove that the interrupt disable approach satisfies the mutual exclusion property on a uniprocessor system:

Theorem: If a process P disables interrupts before entering its critical section and enables them after exiting, no other process can execute while P is in its critical section.

Proof:

1. Let P be in its critical section with interrupts disabled (IF = 0)
2. Assume, for contradiction, that another process Q begins executing while P is in its critical section
3. For Q to execute, the CPU must have switched context from P to Q
4. Context switches on a uniprocessor occur only through:
   • Timer interrupts (blocked by IF = 0)
   • I/O interrupts (blocked by IF = 0)
   • Explicit yield/sleep (P chose not to do this)
   • Exceptions (separate mechanism, not a voluntary switch)
5. Since P has IF = 0 and hasn't yielded, no context switch can occur
6. Therefore, Q cannot execute—contradiction
7. Thus, P has exclusive access to the critical section ∎

Key Insight: This proof relies critically on the uniprocessor assumption. On a multiprocessor system, process Q might be running simultaneously on a different CPU, which has its own interrupt flag. Disabling interrupts on CPU₀ says nothing about CPU₁'s behavior.

Modern operating systems provide abstractions over the raw interrupt control instructions, making them safer and more convenient to use. Let's examine how major operating systems expose this functionality.

Linux Kernel Implementation:

The Linux kernel provides a family of functions for interrupt control, each suited to different use cases:

Windows Kernel Implementation:

The Windows kernel uses a concept called IRQL (Interrupt Request Level) to manage interrupt priorities and critical sections:

FreeBSD Implementation:

FreeBSD uses a similar model with critical_enter() and critical_exit() for lightweight critical sections:

The interrupt disable approach has deep historical roots in the evolution of operating systems. Understanding this history illuminates why this technique remains relevant despite its limitations.

The Pre-Interrupt Era (1940s-1950s):

The earliest computers were strictly sequential machines. Programs ran from start to completion without interruption. The concept of multiple programs "sharing" the processor simply didn't exist. The CPU was a scarce, expensive resource operated in batch mode.

The Interrupt Revolution (Late 1950s-1960s):

The introduction of hardware interrupts transformed computing:

• 1959: IBM 709 introduced "I/O channels" with interrupt capabilities
• 1961: MIT CTSS (Compatible Time-Sharing System) pioneered time-sharing using timer interrupts
• 1964: IBM System/360 included sophisticated interrupt architecture
• 1965: Multics design incorporated fine-grained protection and interrupt handling

With interrupts came the first synchronization problems. Engineers quickly discovered that if the operating system could interrupt a program at any point, data structures accessed by both user code and interrupt handlers could become corrupted.

The CLI/STI Solution:

The natural solution was to give privileged code the ability to temporarily disable interrupts. This was simple, fast, and absolutely effective on the single-processor machines of the era.

Significance in OS Design:

The interrupt disable mechanism became the primitive building block upon which other synchronization mechanisms were built:

1. Semaphores: Early implementations of wait() and signal() disabled interrupts to atomically decrement/increment the semaphore counter and manipulate wait queues

2. Spinlocks: On multiprocessor systems, spinlocks combine atomic test-and-set operations with interrupt disabling to ensure the lock holder isn't preempted

3. Scheduler Locks: The operating system's scheduler itself runs with interrupts disabled during critical operations like context switching and run queue manipulation

4. Interrupt Handlers: Interrupt handlers often run with their own interrupt level disabled to prevent recursive invocation

Legacy in Modern Systems:

Even in contemporary operating systems, interrupt disabling remains essential in specific contexts:

• Kernel initialization code runs with interrupts disabled until all data structures are ready
• Power management transitions disable interrupts during sensitive CPU state changes
• Real-time systems use interrupt control for deterministic timing guarantees
• Debugging and panic handlers disable interrupts to produce coherent crash dumps

We've explored the interrupt disable approach to mutual exclusion in depth. Let's consolidate the essential concepts:

What's Next:

Now that we understand the fundamental mechanism, we'll examine a critical limitation: the interrupt disable approach only works on single-processor systems. In the next page, we'll explore why this is the case and what challenges arise in multiprocessor environments.