Implementation of resilient, atomic data types

Reviewer: Edward A. Feustel

I strongly recommend this paper as a tutorial and exposition of an area of current language research: user defined atomic data types. The purpose of the paper is to explain how resilient, atomic data types which the user needs may be implemented in terms of a set of atomic, resilient data types provided by a programming language. The authors believe that the user will be forced to implement his or her own data types because of efficiency constraints found in the distributed system in which these data types are used. They show that such an implementation is possible within their system but that it is a difficult task. They espouse a design philosophy which systematically trades a simple implementation with no concurrency for a more complex implementation with a higher degree of concurrency. They encourage the reader and the community to try to find alternative approaches which provide a mechanism that is easier to use. The authors' approach is directed to a specific kind of operating system which assumes distributed operation on several nodes that coordinate activity using message passing. Each node has one or more guardian modules totally contained on the node. Each guardian module serves as home for local processes and data. A guardian module permits indirect access to data which its owns (protects and synchronizes) by means of handlers. Guardians have stable state and survive crashes with high probability. If a guardian crashes, its processes die, but it recovers using its stable state to recover the rest of its objects. Guardians are used as the basis for commitment protocol to assure atomic actions over a set of nodes. The authors use a specific language, ARGUS, a descendant of CLU, to implement guardians, built-in atomic types, and atomic actions. ARGUS is designed to perm- it the specification and implementation of user-defined atomic types using the built-in atomic types and stable storage. ARGUS has taken a first cut at atomic types and solving problems with interaction synchronization; making visible to other actions the effects of committed actions; and hiding the effects of aborted actions. Much of the paper describes the features of ARGUS which make the above possible. One important notion in ARGUS is the new data type called mutex. A mutex is an encapsulation of atomic and nonatomic data types and the operations on them which provide for process synchronization. Two operations are defined on a mutex: seize and pause. One seizes a mutex object for the execution of a group of operations. This causes the object to be locked while operations are performed on it. One may temporarily yield a seized mutex object by executing a pause operation. These operations give an effect similar to that of a monitor, but tailored to an environment of commitment. Action synchronization is done by locks on atomic objects. Another important notion in ARGUS is the fact that user-defined atomic types are not informed about commit and abort events, but must ask about the state of atomic actions via properties of the built-in atomic objects. Special language features facilitate the examination and specification of state and commitment. “The representation of a user-defined atomic type is therefore a combination of atomic and nonatomic objects with the nonatomic objects used to hold information that can be accessed by concurrent actions, and the atomic objects containing information that allows the nonatomic data to be interpreted properly.” Resilience is implemented by ARGUS in the following manner: “Each guardian can specify that some of its objects are stable objects. Each stable object has a backup copy kept on stable storage. New backup copies must be written to stable storage for all stable objects modified by committed actions. This copying can happen when the change takes place or after the change takes place; it must happen before an action can commit.” ARGUS provides procedures which indicate when an atomic or a mutex object has changed and must be copied to stable storage. The paper features several detailed examples. A lengthy bibliography is also included.