View-centric reasoning for Linda and Tuple Space computation

M.L. Smith, R.J. Parsons, C.E. Hughes
2003 IEE Proceedings - Software  
In contrast to sequential computation, concurrent computation gives rise to parallel events. Efforts to translate the history of concurrent computations into sequential event traces result in the potential uncertainty of the observed order of these events. Loosely coupled distributed systems complicate this uncertainty even further by introducing the element of multiple imperfect observers of these parallel events. Properties of such systems are difficult to reason about, and in some cases,
more » ... mpts to prove safety or liveness lead to ambiguities. We present a survey of challenges of reasoning about properties of concurrent systems. We then propose a new approach, view-centric reasoning, that avoids the problem of translating concurrency into a sequential representation. Finally. we demonstrate the usefulness of view-centric reasoning as a framework for disambiguating the meaning of tuple space predicate operations, versions of which exist commercially in IBM's T Spaces and Sun's JavaSpaces. Commonly employed models of concurrent systems fail to support reasoning that accounts for multiple inconsistent and imperfect observers of a system's behavior. We overcome these limitations with a new framework, called View-Centric Reasoning (VCR), that addresses issues arising from inconsistent and imperfect observation. The nondeterminism of multiple communicating distributed processes leads to a potentially intractable combinatorial explosion of possible behaviors. By considering the sources of nondeterminism in a distributed system, the policies and protocols that govern choice, and the possible traces and views that result, one can utilize the VCR framework to reason about the behavior of instances of extremely diverse distributed computational models. The organization of this paper is as follows. Section 2 discusses background information concerning Linda and Tuple Space, CSP and VCR concepts. Sections 3 and 4 present details of VCR the model -uninstantiated, instantiated for Linda and Tuple Space, and in support of tuple space composition. Section 5 covers concurrency, its associated challenges, and the event-based reasoning of CSP and VCR. Section 6 concludes with a demonstration of the usefulness of VCR to reason about properties of computation in tuple space that do not appear to be amenable to traditional CSP models. 236 M. L. Smith et al. / VCR for Linda and Tuple Space Computation Background This section provides a brief background in several areas from which the remainder of this paper builds. Section 2.1 introduces the Linda coordination language and Tuple Space, the environment for Linda programs. Section 2.2 discusses CSP, and its abstractions and techniques for reasoning about concurrency. Finally, Section 2.3 introduces concepts and abstractions for View-Centric Reasoning, a framework that builds upon CSP's contributions to reasoning about concurrency. Linda and Tuple Space The tuple space model and Linda language are due to Gelernter [1]. Linda is distinct from pure message passing-based models (e.g., Actors [2]). Unlike message passing models, tuple space exhibits what Gelernter called communication orthogonality, referring to interprocess communications decoupled in destination, space, and time. The tuple space model is especially relevant to discussion of concurrency due to the current popularity of commercial tuple space implementations, such as Sun's JavaSpaces [3] and IBM's T Spaces [4] . Linda is not a complete programming language; it is a communication and coordination language. Linda is intended to augment existing computational languages with its coordination primitives to form comprehensive parallel and distributed programming languages. The Linda coordination primitives are rd(), in(), out(), and eval(). The idea is that multiple Linda processes share a common space, called a tuple space, through which the processes are able to communicate and coordinate using Linda primitives. A tuple space may be viewed as a container of tuples, where a tuple is simply a group of values. A tuple is considered active if one or more of its values is currently being computed, and passive if all of its values have been computed. A Linda primitive manipulates tuple space according to the template specified in its argument. Templates represent tuples in a Linda program. A template extends the notion of tuple by distinguishing its passive values as either formal or actual, where formal values, or formals, represent typed wildcards for matching. Primitives rd() and in() are synchronous, or blocking operations; out() and eval() are asynchronous. The rd() and in() primitives attempt to find a tuple in tuple space that matches their template. If successful, these primitives return a copy of the matching tuple by replacing any formals with actuals in their template. In addition, the in() primitive, in the case of a match, removes the matching tuple from tuple space. In the case of multiple matching tuples, a nondeterministic choice determines which tuple the rd() or in() operation returns. If no match is found, these operations block until such time as a match is found. The out() operation places a tuple in tuple space. This tuple is a copy of the operation's template. Primitives rd(), in(), and out() all operate on passive tuples. All Linda processes reside as value-yielding computations within the active tuples in tuple space. Any Linda process can create new Linda processes through the eval() primitive. Execution of the eval() operation places an active tuple in tuple space, copied from the template. When a process completes, it replaces itself within its respective tuple with the value resulting from its computation. When all processes within a tuple replace themselves with values, the formerly active tuple becomes passive. Only passive tuples are visible for matching by the rd() and in() primitives; thus active tuples are invisible. Communication orthogonality refers to three desirable attributes that seem particularly well-suited for distributed computing. Tuple space acts as a conduit for the generation, use, and consumption of information between distributed processes. First, unlike message passing systems, where a sender must typically specify a message's recipient, information generators M. L. Smith et al.
doi:10.1049/ip-sen:20030129 fatcat:7fqbvinr3bf2xlcw4lz4mnvdri