The 'predicated' forms of the LINDA in and rd primitives have given problems for both kernel implementors and LINDA formalists. This paper firstly analyses these problems and then proposes a precise semantics for inp which is both reasonable, in that it does not admit unexpected or useless implementations, and implementable for open distributed tuple-space systems. The semantics is given in a CSP style by the introduction of several new operators including kick-start, and deadlock-breaking

more »

... rrency which together enable a variety of well-defined, and feasibly implementable interpretations. The paper includes a discussion of the implementation of these operators, and examples of the use of the resulting inp in practical coordination applications. * Jeremy.Jacob@cs.york.ac.uk † Alan. Wood@cs.york.ac.uk The problems arise with the use of the word "can't". There can be many interpretations of this, ranging from "provably cannot for all possible future process behaviours" to "are not willing to supply a tuple at the moment". These two extremes are both unacceptable in practice since the first case is uncomputable (at least for open systems), and the second conveys no useful information -they will be referred to as the 'impossible', and 'useless' semantics of inp in this paper. Presumably, programmers have neither of these interpretations in mind when they feel the need to use an inp -they must believe that some useful information can be gained from its use. Consequently, rather than dismiss the desire for inp as aberrant, and indicating the need for re-education, it is worth trying to overcome the problems with the operation and provide a principled version which goes some way to meet the programmer's requirements. There are two possible cases when using an inp in place of an in might be felt necessary: