11.7 Machine Memory Order

► |  | The Racket Reference

1 | Language Model
2 | Notation for Documentation
3 | Syntactic Forms
4 | Datatypes
5 | Structures
6 | Classes and Objects
7 | Units
8 | Contracts
9 | Pattern Matching
10 | Control Flow
11 | Concurrency and Parallelism
12 | Macros
13 | Input and Output
14 | Reflection and Security
15 | Operating System
16 | Memory Management
17 | Unsafe Operations
18 | Running Racket
| Bibliography
| Index

▼ | 11 | Concurrency and Parallelism

11.1 | Threads
11.2 | Synchronization
11.3 | Thread-Local Storage
11.4 | Futures
11.5 | Places
11.6 | Engines
11.7 | Machine Memory Order

On this page:

memory-order-acquire
memory-order-release

top contents ← prev up next →

#### 11.7`` Machine Memory Order🔗ℹ

Unlike Racket threads, futures and places can expose the underlying machine’s memory model, including a weak memory ordering. For example, when a future writes to multiple slots in a mutable vector, it’s possible on some platforms for another future to observe the writes in a different order or not at all, unless the futures are explicitly synchronized. Similarly, shared byte strings or fxvectors can expose the machine’s memory model across places.

Racket ensures that a machine’s memory model is not observed in a way that unsafely exposes the implementation of primitive datatypes. For example, it is not possible for one future to see a partially constructed primitive value as a result of reading a vector that is mutated by another future.

The box-cas!, vector-cas!, unsafe-box*-cas!, unsafe-vector*-cas!, and unsafe-struct*-cas! operations all provide a machine-level compare-and-set, so they can be used in ways that are specifically supported by the a machine’s memory model. The (memory-order-acquire) and (memory-order-release) operations similarly constrain machine-level stores and loads. Synchronization operations such as place messages, future touches, and future semaphores imply suitable machine-level acquire and release ordering.

> procedure (memory-order-acquire) → void?
> procedure (memory-order-release) → void?

Those operations implement a machine-level memory fence on platforms where one is needed for synchronization. The memory-order-acquire operation ensures at least a load–load and load–store fence at the machine level, and the memory-order-release operation ensures at least a store–store and store–load fence at the machine level.

Added in version 7.7.0.11 of package base.

top contents ← prev up next →