Which of the following ensures mutual exclusion in concurrent processes?

Mutual exclusion requires that when multiple processes or threads share a critical section, at most one of them executes inside it at any instant. Operating systems achieve this through several general mechanisms — semaphore-based blocking, software algorithms such as Peterson's solution, and atomic hardware instructions. Hardware-based approaches use an operation that reads a shared lock variable and updates it in a single indivisible step, so no other process can see or act on an in-between state; the classic hardware primitive for this is the Test-and-Set (TSL) instruction.

Trace how a spinlock built on test-and-set enforces this in practice:

1. The lock variable starts at false (unlocked), and every process trying to enter the critical section repeatedly calls TestAndSet(&lock) until it returns false.

2. TestAndSet atomically reads the current value of lock, sets lock to true, and returns the value it read — the read and the write happen as one uninterruptible hardware step.

3. The first process to call TestAndSet gets back false (lock was unlocked), so its loop exits and it proceeds into the critical section, and lock is now true.

4. Any other process calling TestAndSet while the first is inside the critical section reads back true (lock is already held), so its loop keeps spinning instead of entering — it can never slip in during the gap between the read and the write, because there is no gap.

5. When the first process finishes, it sets lock back to false, allowing exactly one waiting process to succeed on its next TestAndSet call.

boolean TestAndSet(boolean *target) {
    boolean rv = *target;
    *target = true;
    return rv;
}

// Each process:
while (TestAndSet(&lock))
    ;              // busy-wait
// critical section
lock = false;

Contrast with the other options: unbuffered I/O only controls when a single process's output is flushed to a device, not how multiple processes coordinate; environment variables are key-value settings copied into a process's own address space at creation time; command-line arguments (argv) are launch-time parameters whose values are fixed when a program starts, though the process may go on reading them repeatedly during its run. None of these three involve a shared, atomically-updated variable, so none can serialize access between concurrently running processes.

Among the options offered here, only an atomic hardware instruction such as test-and-set removes the window in which two processes could both see the lock as free at once; the other three options never touch any shared, atomically-updated variable at all, so none of them can serialize access between concurrent processes.