Santa Claus

Abstract

With the commercial development of multicore processors, the challenges of writing multithreaded programs to take advantage of these new hardware architectures are becoming more and more pertinent. Concurrent programming is necessary to achieve the performance that the hardware offers. Traditional approaches present concurrency as an advanced topic: they have proven difficult to use, reason about with confidence, and scale up to high levels of concurrency. This article reviews process-oriented design, based on Hoare's algebra of Communicating Sequential Processes (CSP), and proposes that this approach to concurrency leads to solutions that are manageable by novice programmers; that is, they are easy to design and maintain, that they are scalable for complexity, obviously correct, and relatively easy to verify using formal reasoning and/or model checkers. These solutions can be developed in conventional programming languages (through CSP libraries) or specialized ones (such as occam-π) in a manner that directly reflects their formal expression. Systems can be developed without needing specialist knowledge of the CSP formalism, since the supporting mathematics is burnt into the tools and languages supporting it. We illustrate these concepts with the Santa Claus problem, which has been used as a challenge for concurrency mechanisms since 1994. We consider this problem as an example control system, producing external signals reporting changes of internal state (that model the external world). We claim our occam-π solution is correct-by-design, but follow this up with formal verification (using the FDR model checker for CSP) that the system is free from deadlock and livelock, that the produced control signals obey crucial ordering constraints, and that the system has key liveness properties.

To boldly go: an occam-π mission to engineer emergence

“…The lack of central control implied by the descriptions above means that, for simplicity, concurrency will be a fundamental part of the solution. Our computational architecture, patterns and systems are written in occam-π [52,7,58,53,54,31,59,32,40,8], whose processes are sufficiently lightweight to enable a sufficiently large number (e.g. millions) to be run interactively for real-time experiments on emergent behaviour.…”

“…For further information, a condensed summary of the core occam-π syntax and semantics is given in sections 2 and 3 of [58]; much greater detail can be found in [52,53,51]. A different case-study (modelling the formation of blood clots) is reported in [32] and contains considerable lengths of occam-π code (and pseudo-code); however, its architecture is an earlier and more memory-intensive version of the one reported here.…”

“…Process oriented design: components and connectors (from [58]). There are no rules for the shapes of component icons (processes) -whatever is meaningful to the designer is allowed.…”

Refining Santa: An Exercise in Efficient Synchronization

“…Peyton Jones gives a solution in Haskell using software transactional memory [14]. Welch and Pedersen present a process-oriented solution using Occam and discuss model-checking a CSP formulation of the problem [17]. This paper develops a solution using concurrent objects by a series of refinement steps.…”