Relaxed Memory Model¶
The execution of a WebAssembly program gives rise to a trace of events. WebAssembly’s relaxed memory model constrains the observable behaviours of the program’s execution by defining a consistency condition on the trace of events.
Note
A relaxed memory model is necessary to describe the behaviour of programs exhibiting shared memory concurrency. WebAssembly’s relaxed memory model is heavily based on those of C/C++11 and JavaScript. The relaxed memory model described here is derived from the following article: 1.
Preliminary Definitions¶
The above operations on actions are raised to operations on events, indexed by region.
Traces¶
Todo
novel notation here?
A trace is a coinductive list of events. A trace is considered to be a pre-execution of a given global configuration if it represents the events emitted by the coinductive closure of the global reduction relation on that configuration, such that all of the trace’s consituent events have unique time stamps that are totally ordered according to the reduction order.
When a WebAssembly program is executed, all behaviours observed during that execution must correspond to a single consistent pre-execution of that execution’s starting configuration.
Consistency¶
Note
The following is a non-normative and non-exhaustive explanation of WebAssembly’s relaxed memory model in plain English. Note that the definition of Consistency is the sole normative definition of the relaxed memory model.
When a WebAssembly operation reads from shared mutable state, the WebAssembly relaxed memory model determines the value that this read access observes, in terms of the write access to the same location(s) that have occurred in the execution.
The WebAssembly memory model is built around the concept of a happens-before transitive partial order between accesses of shared mutable state,
In the case that a read operation is a multi-byte memory access, the value of each byte may in certain circumstances be determined by a different write event. If this happens, we describe the read operation as tearing. In general, naturally aligned multi-byte reads are not allowed to tear, unless they race with a partially overlapping write or are greater than four bytes in width.
Most WebAssembly accesses of shared mutable state are classified as non-atomic. However a number of operations are classified as performing atomic accesses. Atomic accesses must always be naturally aligned. If an atomic read takes its value from an atomic write of the same width, the write access is fixed as coming before the read access in
WebAssembly’s atomic operations are also required to be sequentially consistent. The relaxed memory model defines a toal order on all events of the execution,
Some operations such as memory accesses must perform a bounds check in addition to accessing data. The relaxed memory model treats these accesses as additionally accessing a distinguished length location, with the observed value respecting the constraints of the relaxed memory model. Most bounds checks are non-atomic, but bounds checks peformed during instantiation are atomic, and changes to the length (e.g.
In some circumstances, two accesses to overlapping locations may occur in an execution without any relation in
The relaxed memory model also describes the concurrent behaviour of WebAssembly’s wait (
- 1
The semantics of the relaxed memory model is derived from the following article: Conrad Watt, Andreas Rossberg, Jean Pichon-Pharabod. Weakening WebAssembly. Proceedings of the ACM on Programming Languages (OOPSLA 2019). ACM 2019.