Transactional monitors are proposed as an alternative to monitors based on mutualexclusion synchronization for object-oriented programming languages. Transactional monitors have execution semantics similar to mutual-exclusion monitors but implement monitors as lightweight transactions that can be executed concurrently (or in parallel on multiprocessors). They alleviate many of the constraints that inhibit construction of transparently scalable and robust applications. We undertake

. The explicitly parallel programming language Eden adds a coordination level to the lazy functional language Haskell. This paper describes how a compiler and runtime system for Eden can incrementally be built on the basis of a compiler and runtime system for the computation language. The modifications needed in the compiler are restricted to specific orthogonal extensions. We show that Eden's design for distributed memory systems proves beneficial for the construction of a lean parallel runtime system. 1 Introduction Due to the side effect freedom of the reduction semantics of functional languages it is possible to evaluate independent subexpressions in arbitrary order or in parallel. This implicit parallelism is semantically transparent and allows the automatic parallelization of functional programs. In available parallel functional systems like the Glasgow parallel Haskell (GpH) system [17] or the Nijmegen CLEAN system [19] the programmer is asked to place annotations in programs. ...

Abstract not found

The parallel functional programming language Eden was specially designed to be implemented in a distributed setting. In a previous paper [3] we presented an operational specification of DREAM, the distributed abstract machine for Eden. In this paper we go a step further and present the imperative code generated for Eden expressions and how this code interact with the distributed RunTime System (RTS) for Eden. This translation is done in two steps: first Eden is translated into PEARL (Parallel Eden Abstract Reduction Language), the parallel functional language of DREAM, and then PEARL expressions are translated into imperative code.

: We investigate two similar but contrasting parallel functional language designs: Eden and GPH. Both languages use the non-strict functional language Haskell as a core expression language, both are implemented as extensions of the high performance Glasgow Haskell Compiler (GHC), and both implementations are available on the same distributed architecture: a Beowulf cluster. This allows an exceptionally pure comparison of the language design characteristics and their impact on parallel performance. The comparison is illustrated by two parallel symbolic computation benchmarks which expose differences in the communication, process creation, and work distribution mechanisms employed by Eden and GPH. Our results show that the explicit process model favoured by Eden gives good parallel performance for coarse-grained applications running on the Beowulf cluster. In comparison, the current GPH implementation of implicit parallelism yields poorer absolute speedup for these two applications. Further work is needed to determine whether this difference is an implementation artefact or a consequence of the different models employed in each case, though excessively fine thread granularity appears to be a contributing factor. 1 Department of Computing and Electrical Engineering, Heriot-Watt University, Scotland; Email: {hwloidl,trinder}@cee.hw.ac.uk 2 Department of Computer Science, Marburg University, Germany; Email: {klusik,loogen}@mathematik.uni-marburg.de 3 School of Computer Science, University of St Andrews, Scotland; Email: kh@dcs.st-andrews.ac.uk 39 4.1

Parallel graph reducers such as GUM use dynamic techniques to manage resources during execution. One important aspect of the dynamic behaviour is the distribution of work. The load balancing mechanism, which controls this aspect, should be flexible, to adjust the distribution of work to hardware characteristics as well as dynamic program characteristics, and scalable, to achieve high utilisation of all processors even on massively parallel machines.

. Parallel programs must describe both computation and coordination, i.e. what to compute and how to organize the computation. In functional languages equational reasoning is often used to reason about computation. In contrast, there have been many different coordination constructs for functional languages, and far less work on reasoning about coordination. We present an initial semantics for GpH, a small extension of the Haskell language, that allows us to reason about coordination. In particular we can reason about work, average parallelism and runtime. The semantics captures the notions of limited (physical) resources, the preservation of sharing, and speculative evaluation. We show a consistency result with Launchbury's well-known lazy semantics. 1 Introduction One of the advantages of declarative languages is that it is relatively easy to reason about the values computed by programs, this being attributable to their preservation of referential transparency. Indeed, within the fun...

. Algorithmic skeletons dene general patterns of computation which are useful for exposing the computational structure of a program. Being general structures they qualify as a target for parallelisation, which is most often carried out by providing specialised, non-portable, low-level parallel implementations (architectural skeletons) of each algorithmic skeleton for dierent platforms. In the paper we introduce an intermediate layer of implementation skeletons for the parallel functional language Eden. These are portable high-level skeletons which simplify the design of parallel programs substantially. Runtime experiments on a network of workstations and on a Beowulf cluster have shown that even on such high-latency parallel platforms good speedups can be obtained. 1

. We describe automatic bypassing, a desirable optimization of Eden's implementation aimed at reducing the number of messages and/or threads at runtime. Eden [BLOMP97] extends the lazy functional language Haskell with a set of coordination features, aimed to express parallel algorithms. These include process abstractions (or process schemes) and process instantiations (or applications of a process scheme to actual inputs). When a new process is instantiated, their input and output channels are connected to its parent process. This implies that, in principle, only tree--like process topologies can be created. But the aimed topology may not be hierarchical (e.g. pipelines, grids, etc.). It is desirable to be able to connect every producer to its actual consumer, trying to avoid the intermediate processes frequently used only to set up the topology. The strategy consists of a combination of compile time analysis and runtime support. Both are explained in detail. Also, the savin...

Abstract. This chapter describes Hume: a functionally-based language for programming with bounded resource usage, including time and space properties. The purpose of the Hume language design is to explore the expressibility/costability spectrum in resource-constrained systems, such as real-time embedded or control systems. It is unusual in being based on a combination of λ-calculus and finite state machine notions, rather than the more usual propositional logic, or flat finite-state-machine models. The use of a strict, purely functional programming notation allows the construction of a strong cost model for expressions, which can then be embedded into a simple cost model for processes. In this chapter, we introduce Hume, describe the Hume Abstract Machine implementation, and show how a high-level cost model can be constructed that relates costs from the abstract machine to Hume source programs. We illustrate our approach with an example adapted from the literature: a simple vending machine controller. 1