Mutual Exclusion Using Interrupt Disabling

---

---

In any operating system, many processes run together and many times they want to use the same shared variable or shared data. Whenever a process is using some shared resource, we say that the process is inside a critical section. The main rule of a critical section is very simple but very important: no two processes should be inside the same critical section at the same time.

If two processes enter the critical section at the same time, data will get corrupted, wrong results will come, system may behave strange. So, a method is needed that makes sure only one process enters at a time. This method is called mutual exclusion.

There are many techniques to achieve mutual exclusion. One simple but old technique is by using interrupt disabling. This chapter explains how it works, why it works, its problems, and where it is useful.

What is Mutual Exclusion?

Before going into interrupt disabling, first understand mutual exclusion itself. Whenever a process is in the critical section, no other process should enter. That means only one process at a time should be allowed. This protects the shared data from accidental changes.

Example: Imagine you and your friend both are trying to update the same bank balance. If both update at the same time without any rules, both values may clash and final balance will be wrong. OS solves this problem through mutual exclusion.

In simple words: Mutual exclusion ensures only one process uses the critical section at a time.

Mutual Exclusion Problem with Priority

Sometimes processes have different priority levels. A higher priority process may preempt (stop) a lower priority process while it is still inside the critical section. This is dangerous because the lower priority process did not finish updating the shared data. So, the OS needs a strong rule to prevent such interference. This is where interrupt disabling can give a simple solution.

Interrupts and Process Switching

Before understanding the solution, we must understand what interrupts do. An interrupt is basically a signal that tells the CPU to stop its current process and handle something else.

Interrupts come from hardware, timer, keyboard, disk, or even from software sometimes. Whenever an interrupt occurs, the CPU switches from the running process to another activity or another process.

There are two main kinds of events that can cause the CPU to switch processes −

• Internal events − The running thread or process does something that gives up the CPU.
• External events − Interrupts coming from outside, like timer or hardware signals.

If we want to stop process switching completely for a short time, then both internal events and external events must be blocked. Internal events can be avoided by writing code carefully. But external events require something stronger.

The only way to stop external events is by disabling interrupts

Once interrupts are disabled, the CPU will not switch to another process. It will continue running the current process, without any interference.

Mutual Exclusion Using Interrupt Disabling

The most straightforward way to get mutual exclusion is to let a process disable interrupts before entering the critical section. When interrupts are disabled, the OS cannot switch to another process. Therefore, the current process gets full safety while dealing with shared variables.

Whenever interrupts are disabled, scheduling stops. No other process can be given the CPU. This means only the current process can touch the shared data.

This method works well in uniprocessor systems, where only one CPU is running at a time. Because if interrupts are disabled, CPU will execute instructions one after another without any break, and context switch will not occur.

So, as long as the process stays in the critical section, no one else can forcefully jump in.

Why Interrupt Disabling Gives Mutual Exclusion

To understand why disabling interrupts gives mutual exclusion, think of the following −

• The CPU runs only one process at a time.
• Process switching happens only at well-defined points.
• These switching points mostly depend on interrupts.

So if interrupts are disabled −

• No external interrupt can arrive.
• No timer interrupt can arrive.
• No hardware interrupt can arrive.
• Therefore, no context switch can happen.

If no context switch can happen, then no other process can enter the critical section. This gives complete protection to the shared data, at least in a uniprocessor system.

Requirements of Mutual Exclusion

Mutual exclusion needs some conditions −

• No two processes should enter at the same time.
• Execution inside critical section must be atomic.
• No process should be delayed unnecessarily.
• No external force should interrupt the critical section.

When interrupts are disabled, all these points are satisfied in a simple way. Because the CPU is now fully under control of the current process, and no other process can run.

Problems with Interrupt Disabling

Even though this method is simple, it also brings many problems. That is why modern operating systems do not depend on this method too much.

System Clock Depends on Interrupts

A computer's clock keeps time by receiving regular interrupts from a timer device. If interrupts are disabled, these timer signals do not reach the CPU. That means the system time can drift or become inaccurate. In some systems, this can create big problems because many tasks depend on correct timing.

Interrupt Disabling on Multiprocessors is Not Effective

On a uniprocessor, disabling interrupts works because only one CPU is present. But on multiprocessor or multi-core systems, other CPUs continue running even if one CPU disables interrupts. So, a process on CPU 1 may disable interrupts, but another process on CPU 2 can still access the shared data. Therefore, mutual exclusion is not guaranteed.

To make it work on multiprocessors, all CPUs must disable interrupts together, which is slow and complicated.

Long Disable Time Locks the System

If a process takes too long inside the critical section, and interrupts remain disabled for that whole time, then −

• keyboard input may not be detected,
• mouse events may not be detected,
• scheduled tasks may get delayed,
• the system may look frozen.

So, disabling interrupts must be used very carefully and for a short time.

Users with Low Priority May Misuse It

If any simple user program gets permission to disable interrupts, the whole OS can become unstable. The system will not be able to switch processes and may hang. That's why user-level programs are not allowed to disable interrupts. Only the OS kernel can do this job.

Not Suitable for Real-Time Systems

Real-time systems need accurate timing, exact scheduling, and must respond quickly to external events. If interrupts are disabled, this accuracy gets lost. So this method is not suitable for real-time operating systems

Internal Events vs External Events

To understand interrupt disabling better, let us see the two types of events that control CPU switching.

Internal Events

Internal events happen inside the running thread. For example,

• A thread voluntarily gives up the CPU.
• A thread goes to wait state.
• A thread makes a system call.

Internal events are easy to handle because the process itself is making the choice.

External Events

External events come from outside the CPU. For example,

• Timer interrupt,
• Keyboard interrupt,
• Disk interrupt,
• Mouse interrupt,
• Network interrupt.

To stop external events temporarily, interrupts must be disabled. This is the only way to guarantee that no unexpected event disturbs the critical section.

Steps in Mutual Exclusion with Interrupt Disabling

Here is how a process uses this technique −

Step 1 − Process wants to enter critical section.

Step 2 − It disables interrupts.

Step 3 − Enters the critical section and updates shared data safely.

Step 4 − Leaves the critical section.

Step 5 − Enables interrupts again.

As long as interrupts are disabled, mutual exclusion is maintained. This method works perfectly for uniprocessor systems, small embedded systems, kernel-level critical operations, very short critical sections (few instructions only). It is not suitable for heavy multitasking or multiprocessor-based systems.

Conclusion

Mutual exclusion using interrupt disabling is one of the simplest and earliest techniques used in operating systems. It ensures that only one process enters the critical section by stopping all interrupts. This prevents the CPU from switching processes and protects shared variables.

But even though this idea is simple, it also has many problems like timing issues, multiprocessor issues, and system freezing. Because of these limitations, modern operating systems rarely use this method directly, except for very small and fast operations inside the kernel.

Still, understanding this method is important because it explains how early OS designs worked and how basic mutual exclusion ideas started. Today's locks, semaphores, and other synchronization methods evolved from these early ideas.