441 research outputs found
Open Transactions on Shared Memory
Transactional memory has arisen as a good way for solving many of the issues
of lock-based programming. However, most implementations admit isolated
transactions only, which are not adequate when we have to coordinate
communicating processes. To this end, in this paper we present OCTM, an
Haskell-like language with open transactions over shared transactional memory:
processes can join transactions at runtime just by accessing to shared
variables. Thus a transaction can co-operate with the environment through
shared variables, but if it is rolled-back, also all its effects on the
environment are retracted. For proving the expressive power of TCCS we give an
implementation of TCCS, a CCS-like calculus with open transactions
Static Application-Level Race Detection in STM Haskell using Contracts
Writing concurrent programs is a hard task, even when using high-level
synchronization primitives such as transactional memories together with a
functional language with well-controlled side-effects such as Haskell, because
the interferences generated by the processes to each other can occur at
different levels and in a very subtle way. The problem occurs when a thread
leaves or exposes the shared data in an inconsistent state with respect to the
application logic or the real meaning of the data. In this paper, we propose to
associate contracts to transactions and we define a program transformation that
makes it possible to extend static contract checking in the context of STM
Haskell. As a result, we are able to check statically that each transaction of
a STM Haskell program handles the shared data in a such way that a given
consistency property, expressed in the form of a user-defined boolean function,
is preserved. This ensures that bad interference will not occur during the
execution of the concurrent program.Comment: In Proceedings PLACES 2013, arXiv:1312.2218. [email protected];
[email protected]
Correctness of an STM Haskell implementation
A concurrent implementation of software transactional memory in Concurrent Haskell using a call-by-need functional language with processes and futures is given. The description of the small-step operational semantics is precise and explicit, and employs an early abort of conflicting transactions. A proof of correctness of the implementation is given for a contextual semantics with may- and should-convergence. This implies that our implementation is a correct evaluator for an abstract specification equipped with a big-step semantics
Towards Efficient Abstractions for Concurrent Consensus
Consensus is an often occurring problem in concurrent and distributed
programming. We present a programming language with simple semantics and
build-in support for consensus in the form of communicating transactions. We
motivate the need for such a construct with a characteristic example of
generalized consensus which can be naturally encoded in our language. We then
focus on the challenges in achieving an implementation that can efficiently run
such programs. We setup an architecture to evaluate different implementation
alternatives and use it to experimentally evaluate runtime heuristics. This is
the basis for a research project on realistic programming language support for
consensus.Comment: 15 pages, 5 figures, symposium: TFP 201
A Lazy Approach for Supporting Nested Transactions
Transactional memory (TM) is a compelling alternative to traditional synchronization, and implementing TM primitives directly in hardware offers a potential performance advantage over software-based methods. In this paper, we demonstrate that many of the actions associated with transaction abort and commit may be performed lazily -- that is, incrementally, and on demand. This technique is ideal for hardware, since it requires little space or work; in addition, it can improve performance by sparing accesses to committing or aborting locations from having to stall until the commit or abort completes.
We further show that our lazy abort and commit technique supports open nesting and orElse, two language-level proposals which rely on transactional nesting. We also provide design notes for supporting lazy abort and commit on our own hardware TM system, based on VTM
Towards a dynamic pipeline framework implemented in (parallel) Haskell
Streaming processing has given rise to new computation paradigms to provide effective and efficient data stream processing. The most important features of these new paradigms are the exploitation of parallelism, the capacity to adapt execution schedulers, reconfigure computational structures, adjust the use of resources according to the characteristics of the input stream and produce incremental results. The Dynamic Pipeline Paradigm (DPP) is a naturally functional approach to deal with stream processing. This fact encourages us to use a purely functional programming language for DPP. In this work, we tackle the problem of assessing the suitability of using (parallel) Haskell to implement a Dynamic Pipeline Framework (DPF). The justification of this choice is twofold. From a formal point of view, Haskell has solid theoretical foundations, providing the possibility of manipulating computations as primary entities. From a practical perspective, it has a robust set of tools for writing multithreading and parallel computations with optimal performance. As proof of concept, we present an implementation of a dynamic pipeline to compute the weakly connected components of a graph (WCC) in Haskell (a.k.a. DPWCC). The DPWCC behavior is empirically evaluated and compared with a solution provided by a Haskell library. The evaluation is assessed in three networks of different sizes and topology. Performance is measured in terms of the time of the first result, continuous generation of results, total time, and consumed memory. The results suggest that DPWCC, even naive, is competitive with the baseline solution available in a Haskell library. DPWCC exhibits a higher continuous behavior and can produce the first result faster than the baseline. Albeit initial, these results put in perspective the suitability of Haskell’s abstractions for the implementation of DPF. Built on them, we will develop a general and parametric DPF in the future.Postprint (published version
- …