9,303 research outputs found

    Graceful Termination -- Graceful Resetting

    Get PDF
    Correct β€” let alone graceful β€” termination of parallel systems is sometimes thought to be a difficult problem. This is particularly imagined to be so under the pure message-passing MIMD discipline of occam and transputer networks, where global operations (like setting a shared flag or abortions) are not allowed and where time-outs cannot be set for every communication. This paper describes some common, but erroneous, occam approaches to this problem and contrasts them with what can be done in Ada [0, 1, 2]. These methods are all rejected on the grounds of insecurity and performance overheads. A simple, legal, secure and efficient occam method is then presented. This method also solves a much more important problem β€” the general (or partial) resetting of a parallel system (or sub-system). The resetting mechanism is quite independent of the parallel application algorithm, which can therefore be developed without worrying about such matters. This separation of concerns is good software engineering and is fully supported by the occam philosophy. Finally, an application of this resetting mechanism is described that permits the dynamic reconstruction of occam network topologies

    pony - The occam-pi Network Environment

    Get PDF
    Although concurrency is generally perceived to be a `hard' subject, it can in fact be very simple --- provided that the underlying model is simple. The occam-pi parallel processing language provides such a simple yet powerful concurrency model that is based on CSP and the pi-calculus. This paper presents pony, the occam-pi Network Environment. occam-pi and pony provide a new, unified, concurrency model that bridges inter- and intra-processor concurrency. This enables the development of distributed applications in a transparent, dynamic and highly scalable way. The first part of this paper discusses the philosophy behind pony, explains how it is used, and gives a brief overview of its implementation. The second part evaluates pony's performance by presenting a number of benchmarks

    Life of occam-Pi

    Get PDF
    This paper considers some questions prompted by a brief review of the history of computing. Why is programming so hard? Why is concurrency considered an β€œadvanced” subject? What’s the matter with Objects? Where did all the Maths go? In searching for answers, the paper looks at some concerns over fundamental ideas within object orientation (as represented by modern programming languages), before focussing on the concurrency model of communicating processes and its particular expression in the occam family of languages. In that focus, it looks at the history of occam, its underlying philosophy (Ockham’s Razor), its semantic foundation on Hoare’s CSP, its principles of process oriented design and its development over almost three decades into occam-? (which blends in the concurrency dynamics of Milner’s ?-calculus). Also presented will be an urgent need for rationalisation – occam-? is an experiment that has demonstrated significant results, but now needs time to be spent on careful review and implementing the conclusions of that review. Finally, the future is considered. In particular, is there a future

    An occam Style Communications System for UNIX Networks

    Get PDF
    This document describes the design of a communications system which provides occam style communications primitives under a Unix environment, using TCP/IP protocols, and any number of other protocols deemed suitable as underlying transport layers. The system will integrate with a low overhead scheduler/kernel without incurring significant costs to the execution of processes within the run time environment. A survey of relevant occam and occam3 features and related research is followed by a look at the Unix and TCP/IP facilities which determine our working constraints, and a description of the T9000 transputer's Virtual Channel Processor, which was instrumental in our formulation. Drawing from the information presented here, a design for the communications system is subsequently proposed. Finally, a preliminary investigation of methods for lightweight access control to shared resources in an environment which does not provide support for critical sections, semaphores, or busy waiting, is made. This is presented with relevance to mutual exclusion problems which arise within the proposed design. Future directions for the evolution of this project are discussed in conclusion

    Coupling the PLANKTOM5.0 marine ecosystem model to the OCCAM 1ΒΊ ocean general circulation model for investigation of the sensitivity of global biogeochemical cycles to variations in ecosystem complexity and physical environment

    Get PDF
    The earliest marine ecosystem models consisted of a simple representation of the main features of marine ecosystems, including, typically, variables for phytoplankton, zooplankton, nutrient and detritus (NPZD models). These have been incorporated into ocean general circulation models to give a basic representation of ecosystem function, providing predictions of bulk quantities such as global primary production, export and biomass which can be compared with available observations. A recent trend has been to increase the number of phytoplankton and zooplankton groups modelled, as analogues of different plankton groups observed to exist in the ocean, for example diatoms and cocolithophores (the so-called plankton functional type or PFT approach). It is usually assumed that the increase in complexity of the model will result in simulated ecosystems which more faithfully reproduce observations than NPZD models, but this has not been demonstrated systematically. The robustness of the PFT models to changes in model parameters and to changes to the physical environment in which it is embedded, have not been investigated. As a first step towards these goals, we incorporate a state-of-the-art PFT model, PLANKTOM5.0 into the OCCAM ocean general circulation model. A 6 year simulation is performed, covering the years 1989-1994 with identical parameter choices to an existing run of PLANKTOM5.0 coupled to the OPA general circulation model. This document describes the development of the coupled model and the 6 year simulation. Comparison with the OPA model and sensitivity of the solution to parameter choices will be described in a forthcoming journal paper

    User-defined data types and operators in occam

    Get PDF
    This paper describes the addition of user-defined monadic and dyadic operators to occam* [1], together with some libraries that demonstrate their use. It also discusses some techniques used in their implementation in KRoC [2] for a variety of target machines

    Higher levels of process synchronisation

    Get PDF
    Four new synchronisation primitives (SEMAPHOREs, RESOURCEs, EVENTs and BUCKETs) were introduced in the KRoC 0.8beta release of occam for SPARC (SunOS/Solaris) and Alpha (OSF/1) UNIX workstations [1][2][3]. This paper reports on the rationale, application and implementation of two of these (SEMAPHOREs and EVENTs). Details on the other two may be found on the web [4]. The new primitives are designed to support higher-level mechanisms of SHARING between parallel processes and give us greater powers of expression. They will also let greater levels of concurrency be safely exploited from future parallel architectures, such as those providing (virtual) shared-memory. They demonstrate that occam is neutral in any debate between the merits of message-passing versus shared-memory parallelism, enabling applications to take advantage of whichever paradigm (or mixture of paradigms) is the most appropriate. The new primitives could be (but are not) implemented in terms of traditional channels, but only at the expense of increased complexity and computational overhead. The primitives are immediately useful even for uni-processors - for example, the cost of a fair ALT can be reduced from O(n) to O(1). In fact, all the operations associated with new primitives have constant space and time complexities; and the constants are very low. The KRoC release provides an Abstract Data Type interface to the primitives. However, direct use of such mechanisms still allows the user to misuse them. They must be used in the ways prescribed (in this paper and in [4]) else their semantics become unpredictable. No tool is provided to check correct usage at this level. The intention is to bind those primitives found to be useful into higher level versions of occam. Some of the primitives (e.g. SEMAPHOREs) may never themselves be made visible in the language, but may be used to implement bindings of higher-level paradigms (such as SHARED channels and BLACKBOARDs). The compiler will perform the relevant usage checking on all new language bindings, closing the security loopholes opened by raw use of the primitives. The paper closes by relating this work with the notions of virtual transputers, microcoded schedulers, object orientation and Java threads

    Guppy: Process-Oriented Programming on Embedded Devices

    Get PDF
    Guppy is a new and experimental process-oriented programming language, taking much inspiration (and some code-base) from the existing occam-pi language. This paper reports on a variety of aspects related to this, specifically language, compiler and run-time system development, enabling Guppy programs to run on desktop and embedded systems. A native code-generation approach is taken, using C as the intermediate language, and with stack-space requirements determined at compile-time
    • …
    corecore