Repository logo
Log in(current)
Repository logoMIT Open ScholarshipDSpace@MIT
  1. Home
  2. Computer Science and Artificial Intelligence Lab (CSAIL)
  3. LCS Publications
  4. LCS Technical Memos (1974 - 2003)
  5. The Mutual Exclusion Problem for Unreliable Processes

The Mutual Exclusion Problem for Unreliable Processes

Thumbnail Image
Download
Name

MIT-LCS-TM-084.pdf

Size

5.73 MB

Format

Adobe PDF

Checksum (MD5)

44a9ab75a2caaa92b186fbf9c564eca1

Author(s)
Rivest, Ronald L.
•
Pratt, Vaughan R.
Date Issued
April 1977
Series/Report no.
MIT-LCS-TM-084
Abstract
Consider n processes operating asynchronously in parallel, each of which maintains a single "public" variable which can be read (but not written) by the other processes. We show that the processes can synchronize their actions by the basic operations of (1) reading each other's public variables, and (2) setting their own public variable to some value. A process may "die" (fail) at any time, when its public variable is (automatically) set to a special "dead" value. A dead process may revive. Reading a public variable which is being simultaneously updated returns either the old or the new value. Each process may be in a certain "critical" state (which it leaves if it dies). We present a synchronization scheme with the following properties. (1) At most one process is ever in its critical state at a time. (2) If a process wants to enter its critical state, it may do so before any other process enters its critical state more than once. (3) The public variables assume only a finite number of values. (4) A process wanting to enter its critical state can always make progress towards that goal. (5) The various processes may run arbitrary speeds relative to one another. By the definition of the problem, no process can prevent another from entering its critical state by repeatedly failing and restartying. In the case of two processes, what makes our solution of particular interest is its remarkable simplicity when compared with the extant solutions to this problem. Our n-process solution uses the two-process solution as a subroutine, and is not quite as elegant as the two-process solution.
Persistent DSpace Link
https://hdl.handle.net/1721.1/148912
Repository logo
PrivacyPermissionsAccessibilityContact us
Repository logo
Notify us about copyright concerns.