distributed mutual exclusion

On a single machine, when two threads must not touch the same data at once, we use a lock or a semaphore: whoever grabs it goes first, the other waits. That works because all the threads share the same memory, so the lock is one object everyone can see. Now spread those participants across different computers with no shared memory. There is no single lock variable to grab. Distributed mutual exclusion is the problem of making sure that, among many separate machines, at most one of them is inside the critical section (using the shared resource) at any moment — using only messages.

Since there is no shared lock, the processes must coordinate by talking. There are a few classic styles. A token-based approach passes a single special message (a token) around the group; you may enter the critical section only while you hold the token, so there is exactly one token and therefore at most one entrant. A permission-based approach (such as the Ricart-Agrawala scheme, which uses logical-clock timestamps to break ties fairly) has a process ask all the others for permission and enter only after everyone agrees. A simpler but more fragile approach uses a central coordinator that hands out the lock like a single ticket window.

Why it matters, and the honest difficulties: distributed mutual exclusion is needed whenever separate machines share something that must not be used by two at once — updating the same record, writing to a shared file, electing who does a job. But it inherits all of distributed computing's pain. Messages take time, so it is slower than a local lock; messages can be lost, so requests and releases can go missing; and a process can crash while holding the token or the lock, freezing everyone unless there is a recovery mechanism. There is a real trade-off between fault tolerance, fairness, and the number of messages each entry costs.