Documentation

When performing compare-and-swaps, the ticket encapsulates proof that a thread observed a specific previous value of a mutable variable. It is provided in lieu of the "old" value to compare-and-swap.

Design note: Tickets exist to hide objects from the GHC compiler, which can normally perform many optimizations that change pointer equality. A Ticket, on the other hand, is a first-class object that can be handled by the user, but will not have its pointer identity changed by compiler optimizations (but will of course, change addresses during garbage collection).

A ticket contains or can get the usable Haskell value. This function does just that.

Ordinary processor load instruction (non-atomic, not implying any memory barriers).

The difference between this function and readIORef, is that it returns a ticket, for use in future compare-and-swap operations.

Performs a machine-level compare and swap (CAS) operation on an IORef. Returns a tuple containing a Bool which is True when a swap is performed, along with the most current value from the IORef. Note that this differs from the more common CAS behavior, which is to return the old value before the CAS occured.

The reason for the difference is the ticket API. This function always returns the ticket that you should use in your next CAS attempt. In case of success, this ticket corresponds to the new value which you yourself installed in the IORef, whereas in the case of failure it represents the preexisting value currently in the IORef.

Note "compare" here means pointer equality in the sense of reallyUnsafePtrEquality#. However, the ticket API absolves the user of this module from needing to worry about the pointer equality of their values, which in general requires reasoning about the details of the Haskell implementation (GHC).

By convention this function is strict in the "new" value argument. This isn't absolutely necesary, but we think it's a bad habit to use unevaluated thunks in this context.