Distributed Systems

Concurrency and Consistency

Matthieu Perrin

• Publisher: ISTE Press - Elsevier
• Year: 2017
• ISBN:
  9780081023174
• Topic: Computer Science
• Subtopic: Data Processing
• Index: Computer Science

Distributed Systems: Concurrency and Consistency explores the gray area of distributed systems and draws a map of weak consistency criteria, identifying several families and demonstrating how these may be implemented into a programming language. Unlike their sequential counterparts, distributed systems are much more difficult to design, and are therefore prone to problems. On a large scale, usability reminiscent of sequential consistency, which would provide the same global view to all users, is very expensive or impossible to achieve. This book investigates the best ways to specify the objects that are still possible to implement in these systems.

• Explores the gray area of distributed systems and draws a map of weak consistency criteria
• Investigates the best ways to specify the objects that are still possible to implement in these systems
• Presents a description of existing memory models and consistency criteria

1

Specification of Shared Objects

Abstract

When a project manager designs the general architecture of an application, one of his main concerns is to divide the workload into distinct logical entities, software building blocks, thus enabling them to be implemented by different developers. Each software building block is then separately specified to mitigate the risks of conflict during the final integration. The specification is thus the communication vector between two developers: the designer who designs the object and the user who uses it in his/her own program. When the object in question is part of a library (and all the more when the source code is proprietary), this is the only way to describe the object. A good specification should be written from the user’s perspective and for the user. We will now describe the three main qualities that a specification must have.

Keywords

Abstract data types; ADT composition communications; Asynchronous processes; Concurrent history; Consistency criteria; Modelization; Sequential specifications; Shared objects

1.1 Introduction

When a project manager designs the general architecture of an application, one of his main concerns is to divide the workload into distinct logical entities, software building blocks, thus enabling them to be implemented by different developers. Each software building block is then separately specified to mitigate the risks of conflict during the final integration. The specification is thus the communication vector between two developers: the designer who designs the object and the user who uses it in his/her own program. When the object in question is part of a library (and all the more when the source code is proprietary), this is the only way to describe the object. A good specification should be written from the user’s perspective and for the user. We will now describe the three main qualities that a specification must have.

Rigor. A specification should not necessarily be an accurate characterization of all the possible reactions of the object. In general, it instead concerns properties verified in all situations. The proper level of detail must be adopted: properties that are too strong excessively constrain the implementation, but too weak constraints only partially depict the semantics of the object. On the other hand, all properties must be perfectly mathematically defined to not give room for subjective interpretation. This is especially true if formal validation techniques are being utilized.

Abstraction. One way to describe the behavior of an object in a rigorous way is to give away its source code. This, however, does not make a good specification. As a matter of fact, code modifications may be necessary in order to improve the efficiency for solving errors, or adapt to a new environment. In all these cases, if the semantics remain the same, there is no reason to change the specification. A specification should be independent of the implementation. For a shared object, the values stored in the local memory of a process and the ...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Acknowledgments
• Introduction
• List of Notations
• 1: Specification of Shared Objects
• 2: Overview of Existing Models
• 3: Update Consistency
• 4: Causal Consistency
• 5: Weak Consistency Space
• 6: CODS Library
• Conclusion
• Bibliography
• Index