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.

Added in version 7.7.0.11 of package base.