Composing first-class transactions

Haines, Nicholas; Kindred, Darrell; Morrisett, J. Gregory; Nettles, Scott; Wing, Jeannette M.

doi:10.1145/197320.197346

Cited by 51 publications

(34 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…First, there is no conceptual problem with treating isolation and parallelism as orthogonal issues (Moss 1985;Haines et al 1994;Jagannathan et al 2005). Second, if e spawns a thread (perhaps inside a library), then e and atomic e behave differently.…”

Section: The Strongnestedparallel Languagementioning

confidence: 99%

High-level small-step operational semantics for transactions

Moore

Grossman

2008

SIGPLAN Not.

View full text Add to dashboard Cite

Software transactions have received significant attention as a way to simplify shared-memory concurrent programming, but insufficient focus has been given to the precise meaning of software transactions or their interaction with other language features. This work begins to rectify that situation by presenting a family of formal languages that model a wide variety of behaviors for software transactions. These languages abstract away implementation details of transactional memory, providing high-level definitions suitable for programming languages. We use small-step semantics in order to represent explicitly the interleaved execution of threads that is necessary to investigate pertinent issues.We demonstrate the value of our core approach to modeling transactions by investigating two issues in depth. First, we consider parallel nesting, in which parallelism and transactions can nest arbitrarily. Second, we present multiple models for weak isolation, in which nontransactional code can violate the isolation of a transaction. For both, type-and-effect systems let us soundly and statically restrict what computation can occur inside or outside a transaction. We prove some key language-equivalence theorems to confirm that under sufficient static restrictions, in particular that each mutable memory location is used outside transactions or inside transactions (but not both), no program can determine whether the language implementation uses weak isolation or strong isolation.

show abstract

Section: The Strongnestedparallel Languagementioning

confidence: 99%

High-level small-step operational semantics for transactions

Moore

Grossman

2008

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…The association of transactions with programming control structures has provenance in systems such as Argus [17,15,18], Camelot [10] Avalon/C++ [9] and Venari/ML [13], and has also been studied for variants of Java, notably by Garthwaite [11] and Daynes [6,7,8]. There is a large body of work that explores the formal specification of various flavors of transactions [16,5,12].…”

Section: Related Workmentioning

confidence: 99%

A Semantic Framework for Designer Transactions

Vítek

Jagannathan

Welc

et al. 2004

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract.A transaction defines a locus of computation that satisfies important concurrency and failure properties; these so-called ACID properties provide strong serialization guarantees that allow us to reason about concurrent and distributed programs in terms of higher-level units of computation (e.g., transactions) rather than lower-level data structures (e.g., mutual-exclusion locks). This paper presents a framework for specifying the semantics of a transactional facility integrated within a host programming language. The TFJ calculus supports nested and multi-threaded transactions. We give a semantics to TFJ that is parameterized by the definition of the transactional mechanism that permits the study of different transaction models.

show abstract

“…A number of researchers describe a way to decompose transactions, and provide support of the isolation property in common programming. For instance, Venari/ML [9] implements higher-order functions in ML to express modular transactions, with concurrency control factored out into a separate mechanism that the programmer could use to ensure isolation.…”

Section: Related Workmentioning

confidence: 99%

“…into services, and to express an arbitrary synchronization policy that will constrain the concurrent execution of services at runtime. Our basic synchronization policies include true parallelism, sequentiality, and the combination of these two policies called isolation, which is analogous to the isolation non-interference property known from multithreaded transactions [9,3]. Isolated services can be assumed to execute serially, without interleaved steps of other services, which significantly simplifies both programming and reasoning about program correctness.…”

Section: Introductionmentioning

confidence: 99%

Concurrency Combinators for Declarative Synchronization

Wojciechowski

2004

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. Developing computer systems that are both concurrent and evolving is challenging. To guarantee consistent access to resources by concurrent software components, some synchronization is required. A synchronization logic, or policy, is at present entangled in the component code. Adding a new component or modifying existing components, which may require a change of the (global) synchronization policy, is therefore subjected to an extensive inspection of the complete code. We propose a calculus of concurrency combinators that allows a program code and its synchronization policy to be expressed separately; the policies include true parallelism, sequentiality, and isolation-only transactions. The calculus is equipped with an operational semantics and a type system. The type system is used to verify if a synchronization policy declared using combinators can be satisfied by program execution.

show abstract

Composing first-class transactions

Cited by 51 publications

References 11 publications

High-level small-step operational semantics for transactions

High-level small-step operational semantics for transactions

A Semantic Framework for Designer Transactions

Concurrency Combinators for Declarative Synchronization

Contact Info

Product

Resources

About