A principal use of concurrent programming is in the implementation of distributed systems. A distributed system consists of processes running in different address spaces on logically different processors. Because the processes are physically disjoint, there are a number of issues that arise in distributed systems that are not present in concurrent programming:

• Communication latency is significantly higher over a network than between threads running in the same address space.

• Processors and network links can go down, and come back up, during the execution of a distributed program.

• Programs running on different nodes may be compiled independently, which means that type security cannot be guaranteed statically.

For these reasons, the synchronous model used in CML does not map well to the distributed setting. A different programming model is required for dealing with remote communication.

Although concurrent programming languages, such as CML, may not directly provide a notation for distributed programming, they do have an important rôle in implementing distributed systems. A distributed system is made up of individual programs running on different machines, which must communicate with each other. Managing this communication is easier in a concurrent language. Furthermore, multiple threads of control can help hide the latency of network communication. For these reasons, most distributed programming languages and toolkits provide concurrent programming features.

This chapter explores a distributed implementation of Linda-style tuple spaces (described in Section 2.6.3).

Concurrent programming differs from sequential programming in several significant ways. Conceptually, we can view the execution of a concurrent program as an interleaving of the sequential execution of its constituent processes. Since there are many possible interleavings, the execution of a concurrent program is nondeterministic; i.e., different interleavings may produce different results. In effect, a concurrent program defines a partial order on its actions, whereas a sequential program defines a total order. This nondeterminism is both the bane and boon of concurrent programming: on the one hand, it creates additional correctness problems, while on the other hand, it provides flexibility and a more natural program structure. As argued in Chapter 1, the choice of programming notation can help the programmer control the complexity of concurrency, while reaping its benefits.

A concurrent language typically consists of a sequential core (or sub-language), extended with support for concurrency. The concurrency support can be divided into three different kinds of mechanism:

• • A mechanism for introducing independent sequential threads of control, called processes. The process creation mechanism can be either static, restricting the program to a fixed number of processes, or dynamic, allowing new processes to be created “on-the-fly.”

• • A mechanism for processes to communicate. Communication involves exchanging data, either through shared memory locations (e.g., variables) or by explicit message passing.

• • And a mechanism for processes to synchronize. Synchronization restricts the ordering of execution in otherwise independent threads, and is used to limit the program's nondeterminism where necessary.

This chapter is the first of three tutorial chapters on the basic features and programming techniques of CML. This chapter focuses on the features that make up CML's semantic core. The next chapter continues with a discussion of the two most important styles of CML programming: process networks and client-server protocols. Chapter 5 completes the tutorial with further discussion of CML's synchronization and communication mechanisms.

Sequential programming

As is the case with most concurrent languages, CML consists of a sequential core language — Standard ML — extended with concurrency primitives. The individual processes in a CML program are programmed using the features of SML. While we conceptually view CML as a programming language, it is actually implemented as a collection of modules on top of SML/NJ. The aspects of CML described in this chapter all belong to the core structure of this library, which is named CML. To reduce notational clutter, most of the examples in this chapter are assumed to be given in an environment where the CML structure has been pre-opened (i.e., all of its bindings are at top-level). The CML structure's interface is described in Appendix A, which contains an abridged version of the CML Reference Manual.

CML is a message-passing language, which means that processes are viewed as executing in independent address spaces with their only communication being via messages. But, since SML provides updatable references, this is a fiction that must be maintained by programming style and convention.

In Chapter 2 it was already mentioned that correctness of an implementation essentially means that the corresponding diagrams commute weakly. Recall that there are four possible ways in which this can be defined, each implying a notion of simulation. This is depicted in Figures 4.1–4.4 for a single operation (note the direction of the inner arrows).

In this chapter the subtle differences between these notions of simulation are studied. Such differences must be taken into account, e.g., when concatenating simulation diagrams. Also we investigate how these notions behave under vertical stacking and how they are related to each other. The outcome has serious consequences for the value of U- and U−1-simulation.

With the necessary technical machinery at hand, we are finally able to show how data invariants can be used to convert partial abstraction relations into total ones.

Then we analyze soundness and completeness of simulation as a method for proving data refinement.

We undertake most of our investigations in a purely semantic set-up, suppressing the distinction between syntax and semantics as much as possible.

Figure 4.1 represents U-simulation, and Figure 4.2 represents L-simulation. The diagrams in Figures 4.3 and 4.4 represent U−1 -simulation and L−1-simulation, respectively. Because a concrete operation can be less nondeterministic than the corresponding abstract operation, we say that the diagrams commute weakly. This weak form of commutativity is expressed by “⊆” in the following definitions. (Strong commutativity would be expressed by “=”.)

Composing Simulation Diagrams

To obtain a compositional theory of simulation, it would be interesting to have a sufficiently strong condition under which these kinds of simulation hold for composed diagrams.

The goal of this monograph is the introduction of, and comparison between, various methods for proving implementations of programs correct. Although these methods are illustrated mainly by applying them to correctness proofs of implementations of abstract data structures, the techniques developed apply equally well to proving correctness of implementations in general. For we shall prove that all these methods are only variations on one central theme: that of proof by simulation, of which we analyze at least 13 different formulations.

As the central result we prove that these methods either imply or are equivalent to L-simulation (also called forward or downward simulation in the literature) or a combination of L- with L−1-simulation (the latter is also called backward or upward simulation). Since, as shown by Hoare, He, and Sanders, only the combination of these forms of simulation is complete, this immediately establishes when these methods are complete, namely, when they are equivalent to this combination.

Our motivation for writing this monograph is that we believe that in this area of computer science (as well as in various other areas) the duty of universities is not to train students in particular methods, but rather to give students insight in both similarities and differences between methods such as VDM, Z, the methods advocated by Reynolds and Hehner, and methods more directly based on Hoare Logic or predicate transformers. The reason for this conviction is that computer science develops far too quickly for us to believe that any of these methods will survive in its present form.

This part presents an overview of some existing formalisms for proving data refinement. We analyze for each of the selected formalisms how it relates to simulation in its various shapes (partial vs. total correctness, relational vs. predicate transformer semantics). This allows us to compare the power of these formalisms when it comes to data refinement. The reader should be warned, however, that this does not at all imply a ranking that should be used as a guideline for selecting a particular method for a development project.

In Chapters 11 and 12, Reynolds' method and VDM are described and related to the results of Part I, and in Chapter 13 this is done for Z, Hehner's method, and Back's refinement calculus. In Section 13.1 we not only introduce the Z-notation and state Z's method for proving data refinement, but also explain why the latter is equivalent, modulo notation, with the VDM method for proving data refinement as stated in Chapter 12. Consequently, Z does not introduce anything new from the point of view of data refinement, although it constitutes a considerable improvement w.r.t. the important topic of structuring specifications.

The main result of these chapters is that these methods can be considered as applications of the L-simulation principle. Back's refinement calculus is similar to the one presented in Chapter 10 in that it is based on weakest precondition predicate transformer semantics and in that its notion of simulation is a kind of powersimulation.

Hoare logic is a formal system for reasoning about Hoare-style correctness formulae. It originates from C. A. R. Hoare's 1969 paper “An axiomatic basis for computer programming” [Hoa69], which introduces an axiomatic method for proving programs correct. Hoare logic can be viewed as the structural analysis of R. W. Floyd's semantically based inductive assertion method.

Hoare's approach has received a great deal of attention ever since its introduction, and has had a significant impact on methods both for designing and verifying programs. It owes its success to three factors:

1. (i) The first factor, which it shares with the inductive assertion method, is its universality: it is state-based, characterizes programming constructs as transformers of states, and therefore applies in principle to every such construct.

2. (ii) The second factor in its success is its syntax directedness: every rule for a composed programming construct reduces proving properties of that construct to proving properties of its constituent constructs. In case the latter are also formulated as Hoare style correctness formulae — when characterizing parallelism this is not always the case — Hoare logic is even compositional: proving Hoare style correctness formulae for composed constructs is reduced to proving Hoare style correctness formulae for their constituent constructs without any additional knowledge about the latter's implementation. Hoare's 1969 logic is compositional.

Compositional Hoare logics can also be regarded as design calculi. In such a design calculus a proof rule is interpreted as a design rule, in which a specific design goal, that of developing a program satisfying certain properties, is reduced to certain subgoals (and, in general, the satisfaction of certain verification conditions), obtained by reading that rule upside-down.

Introduction

In the glossary of terms in his book [J90] Cliff Jones explains the origin of the name Vienna Development Method.

VDM is the name given to a collection of notation and concepts which grew out of the work of the IBM Laboratory, Vienna. The original application was the denotational description of programming languages. The same specification technique has been applied to many other systems. Design rules which show how to prove that a design satisfies its specification have been developed. [J90, p. 294]

Of the techniques mentioned above, Bicarregui et al [BFL+94] stress three as the main ones: the specification language VDM-SL, data refinement techniques, and operation decomposition techniques, where the latter term refers to refinement as opposed to data refinement, for instance, the implementation of a specification statement by a loop.

One keyword in the quote above is ‘rule’. Nowadays the first impression a student might get when learning and practising VDM is that of a huge collection of rules to guide writing specifications. Indeed, specifying with VDM mostly comprises two activities carried out together:

• writing specifications of, e.g., types, functions, and operations in the specification language and

• discarding proof obligations — preferably by formal proof — that ensure, for instance, that a type1 is nonempty, a function specification is well-formed, a specification of an operation is satisfiable, or a specification is implemented by an operation.

• Of course, we focus in this monograph on the proof obligations that arise in the process of data refinement.