The Eden coordination model for distributed memory systems

Breitinger, Silvia; Loogen, Rita; Ortega-Mallén, Yolanda; Peña, Ricardo

doi:10.1109/hips.1997.582964

Cited by 21 publications

(17 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We allow invocation of wait and notify methods inside of a region guarded by a transactional monitor, provided that they are also guarded by a mutualexclusion monitor (and invoked on the object representing that mutual-exclusion monitor 9 ). Invoking wait releases the corresponding mutual-exclusion monitor and the current thread waits for notification, but updates performed so far do not become visible until the thread resumes and exits the transactional monitor.…”

Section: Wait-notifymentioning

confidence: 99%

“…Incorporating explicit concurrency abstractions within high-level languages has a long history [22,23,18,9,36], as does deriving parallelism from unannotated programs either through compiler analysis [31] or through explicit annotations and pragmas [39]. Our ideas differ from these efforts insofar as we are concerned with providing abstractions that simplify the complexity of locking and synchronization.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Transactional Monitors for Concurrent Objects

Welc

Jagannathan

Hosking

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Transactional monitors are proposed as an alternative to monitors based on mutual-exclusion synchronization for object-oriented programming languages. Transactional monitors have execution semantics similar to mutualexclusion 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 a detailed study of alternative implementation schemes for transactional monitors. These different schemes are tailored to different concurrent access patterns, and permit a given application to use potentially different implementations in different contexts. We also examine the performance and scalability of these alternative approaches in the context of the Jikes Research Virtual Machine, a state-of-the-art Java implementation. We show that transactional monitors are competitive with mutualexclusion synchronization and can outperform lock-based approaches up to five times on a wide range of workloads.

show abstract

Section: Wait-notifymentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Transactional Monitors for Concurrent Objects

Welc

Jagannathan

Hosking

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

show abstract

“…The Haskell Community Report [3] mentions two major approaches to parallel computation based on Haskell: Glasgow parallel Haskell [4] and Eden [5]. These two languages show major differences in their coordination concept and, in consequence, in their implementation, while on the other hand, they both capture the main idea of evaluating independent subexpressions in parallel.…”

Section: General-purpose Parallelism In Haskellmentioning

confidence: 99%

“…The parallel Haskell dialect Eden [5] allows to define process abstractions by a constructing function process and to explicitly instantiate (i.e. run) them on remote processors using the operator ( # ).…”

Section: Edenmentioning

confidence: 99%

Towards a Generalised Runtime Environment for Parallel Haskells

Berthold

2004

Computational Science - ICCS 2004

View full text Add to dashboard Cite

Abstract. Implementations of parallel dialects (or: coordination languages) on a functional base (or: computation) language always have to extend complex runtime environments by the even more complex parallelism to maintain a high level of abstraction. Starting from two parallel dialects of the purely functional language Haskell and their implementations, we generalise the characteristics of Haskell-based parallel language implementations, abstracting over low-level details. This generalisation is the basis for a shared runtime environment which can support different coordination concepts and alleviate the implementation of new constructs by a well-defined API and a layered structure.

show abstract

“…That is, the cost of the interaction between newly parallel program components outweighs any benefit from executing them in parallel. Thus, there is considerable research into developing new declarative languages for parallelism, such as Eden [BLOMP97], or extending extant languages, such as Haskell[eAB + 99], again without any wide adoption of a single language or stable standardisation of extensions. Nonetheless, as we shall see, declarative languages do offer valuable abstractions for parallelism in higher order functions (HOFS) which generalise common patterns of computation enabling their efficient realisation as standard patterns of coordination.…”

Section: Overviewmentioning

confidence: 99%

Reasoning about Multi-process Systems with the Box Calculus

Michaelson

Grov

2012

Central European Functional Programming School

View full text Add to dashboard Cite

Abstract. The box calculus is a formalism for reasoning about the properties of multi-process systems which enables account to be taken of pragmatic as well as computational concerns. It was developed for the programming language Hume which explicitly distinguishes between coordination, based on concurrent boxes linked by wires, and expressions, based on polymorphic recursive functions. This chapter introduces Hume expressions and surveys classic techniques for reasoning about functional programs. It then explores Hume coordination and the box calculus, and examines how Hume programs may be systematically transformed while maintaining computational and pragmatic correctness. OverviewHaving constructed programs that meet their specifications, we often want to change them to take advantage of changing operating environments. For example, we might want to migrate a program from environments with smaller to larger numbers of processors to improve performance, in particular as the number of cores grows in new generations of the same CPU architecture. In changing programs, we want to ensure not only they still meet their original specifications, but also that their pragmatic (i.e. time, space, sequencing) behaviours change in well understood ways. In particular, in making what appear to be local improvements to a program, for example by introducing parallelism, we want to avoid unexpected global impacts that make overall performance worse, for example as a result of unanticipated additional communication or scheduling costs. Thus, we need some means of reasoning about changes to programs that can account for pragmatic as well as computational program properties.Most software is constructed in imperative programming languages; abstractions from von Neumann architectures 1 based on sequences of state changes mediated by mutable memory. Here, different program components interact by manipulating the same memory areas. Thus, changing the order of component execution often changes the sequence of memory manipulation, changing what the program does. This complicates reasoning about imperative programs because the state change sequencing must be made explicit in the reasoning 1 And also Harvard architectures.

show abstract

The Eden coordination model for distributed memory systems

Cited by 21 publications

References 8 publications

Transactional Monitors for Concurrent Objects

Transactional Monitors for Concurrent Objects

Towards a Generalised Runtime Environment for Parallel Haskells

Reasoning about Multi-process Systems with the Box Calculus

Contact Info

Product

Resources

About