On Thin Air Reads Towards an Event Structures Model of Relaxed Memory

Jeffrey, Alan; Riely, James

doi:10.1145/2933575.2934536

Cited by 49 publications

(59 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Indeed, we are already working with two large processor vendors to apply our technique to their recent and upcoming architectures and languages. Other future work includes applying our technique to more recent MCMs that are defined in a non-axiomatic style [27,40,41,65].…”

Section: Resultsmentioning

confidence: 99%

Automatically comparing memory consistency models

Wickerson

Batty

Sorensen

et al. 2017

Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

Section: Resultsmentioning

confidence: 99%

Automatically comparing memory consistency models

Wickerson

Batty

Sorensen

et al. 2017

Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

“…In particular, it always chooses option 41 over option 40 . In practice, we find it quicker to obtain (P , Q, σ) by constructing (P , σ) = LIT(X ) and (Q, σ ) = LIT(Y ), rather than by solving the four constraints in Step 2 of (1).…”

Section: Practical Considerationsmentioning

confidence: 99%

Automatically comparing memory consistency models

et al. 2017

View full text Add to dashboard Cite

A memory consistency model (MCM) is the part of a programming language or computer architecture specification that defines which values can legally be read from shared memory locations. Because MCMs take into account various optimisations employed by architectures and compilers, they are often complex and counterintuitive, which makes them challenging to design and to understand. We identify four tasks involved in designing and understanding MCMs: generating conformance tests, distinguishing two MCMs, checking compiler optimisations, and checking compiler mappings. We show that all four tasks are instances of a general constraint-satisfaction problem to which the solution is either a program or a pair of programs. Although this problem is intractable for automatic solvers when phrased over programs directly, we show how to solve analogous constraints over program executions , and then construct programs that satisfy the original constraints. Our technique, which is implemented in the Alloy modelling framework, is illustrated on several software- and architecture-level MCMs, both axiomatically and operationally defined. We automatically recreate several known results, often in a simpler form, including: distinctions between variants of the C11 MCM; a failure of the "SC-DRF guarantee" in an early C11 draft; that x86 is "multi-copy atomic" and Power is not; bugs in common C11 compiler optimisations; and bugs in a compiler mapping from OpenCL to AMD-style GPUs. We also use our technique to develop and validate a new MCM for NVIDIA GPUs that supports a natural mapping from OpenCL.

show abstract

“…gave a generic axiomatic framework for describing weak memory models and showed how to specialize it to various memory models. Jeffrey and Riely [JR19] give a denotational account of relaxed memory models using event structures. Pratt [Pra86] was the first to generalize from traces to pomsets in the study of concurrency.…”

Section: Related Workmentioning

confidence: 99%

A Denotational Semantics for SPARC TSO

Kavanagh

Brookes

2018

Electronic Notes in Theoretical Computer Science

View full text Add to dashboard Cite

The SPARC TSO weak memory model is defined axiomatically, with a noncompositional formulation that makes modular reasoning about programs difficult. Our denotational approach uses pomsets to provide a compositional semantics capturing exactly the behaviours permitted by SPARC TSO. It uses buffered states and an inductive definition of execution to assign an input-output meaning to pomsets. We show that our denotational account is sound and complete relative to the axiomatic account, that is, that it captures exactly the behaviours permitted by the axiomatic account. Our compositional approach facilitates the study of SPARC TSO and supports modular analysis of program behaviour.However, the SPARC ISA provides the weaker SPARC TSO (total store ordering) memory model. Under SPARC TSO, it is possible to start from the aforementioned initial state and end in a state where both z and w are set to one, thus violating mutual exclusion.Weak memory models are often described in standards documents using natural language. This informality makes it difficult to reason about how programs will behave on systems that use these memory models. The SPARC Architecture Manual [SPA92] gives an axiomatic description of TSO using partial orders of actions. We present this description in Section 2; other axiomatic approaches are discussed in Section 5. Despite their formality, it is hard to use axiomatic accounts to reason about the behaviour of programs. This is because the axiomatic approach is non-compositional and precludes modular reasoning. We address this problem by presenting a denotational semantics for SPARC TSO in Section 3. Our denotational semantics assigns to each program a collection of pomsets. Pomsets are generalizations of traces and were first used by Pratt [Pra86] to give denotational semantics for concurrency, and later by Brookes [Bro16a], with some modifications, to study weak memory models. We illustrate our semantics by validating various litmus tests and expected program equivalences. To ensure our denotational semantics accurately captures the behaviour of SPARC TSO, we show in Section 4 that from every denotation of a program we can derive a collection of partial orders satisfying the axiomatic description of Section 2 and, moreover, that we can derive every such partial order from the denotation. An Axiomatic AccountThe SPARC manual [SPA92] gives an axiomatic description of TSO in terms of partial orders of actions. Unfortunately, this description is incomplete because it fails to specify the fork and join behaviour of TSO. In this section, we complete the SPARC manual's account of TSO with an account of forking and joining. Before doing so, we give an informal description of TSO to help build intuition.A system providing the TSO weak memory model can be thought of as a collection of processors, each with a write buffer. Whenever a processor performs a write, it places it in its write buffer. The buffer behaves as a queue, and writes migrate out of the buffers one at a time, and shared memory applies them ac...

show abstract

On Thin Air Reads Towards an Event Structures Model of Relaxed Memory

Cited by 49 publications

References 22 publications

Automatically comparing memory consistency models

Automatically comparing memory consistency models

Automatically comparing memory consistency models

A Denotational Semantics for SPARC TSO

Contact Info

Product

Resources

About