11.7 Machine Memory Order (original) (raw)

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 orfxvectors 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!, andunsafe-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, futuretouches, and future semaphores imply suitable machine-level acquire and release ordering.

Those operations implement a machine-level memory fence on platforms where one is needed for synchronization. Thememory-order-acquire operation ensures at least a load–load and load–store fence at the machine level, and thememory-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.