On this page:

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.


(memory-order-acquire)  void?


(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 of package base.