Changes between Version 3 and Version 4 of AtomicPrimops


Ignore:
Timestamp:
May 20, 2014 3:18:47 PM (14 months ago)
Author:
tibbe
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AtomicPrimops

    v3 v4  
    2727== Implementation
    2828
    29 The primops are implemented as `CallishMachOp`s to allow us to emit LLVM intrinsics when using the LLVM backend. This also allows us to provide a fallback implementation in C on those platforms where we don't want to implement the backend support for these operations. The fallbacks can be implemented using the GCC/LLVM atomic built-ins e.g. `__sync_fetch_and_add`
     29The primops are implemented as `CallishMachOp`s to allow us to emit LLVM intrinsics when using the LLVM backend. This also allows us to provide a fallback implementation in C on those platforms where we don't want to implement the backend support for these operations. The fallbacks can be implemented using the GCC/LLVM atomic built-ins e.g. `__sync_fetch_and_add`.
    3030
    3131=== Ensuring ordering of non-atomic operations
    3232
    33 As the Cmm code generator cannot reorder (TODO: is this true?) reads/writes around prim calls (i.e. `CallishMachOp`s) the `memory_order_seq_cst` semantics should be preserved.
     33A `CallishMachOp` already acts as a memory barrier; the Cmm optimizer will not float loads/stores past it. We'll document the reliance on this behavior in the sinking pass to make sure that if it's ever changed, the optimizer is taught about how to handle these atomic operations in some different way.
     34
     35The `CallishMachOp` will be translated to the correct instructions in the backends (e.g. `lock; add` on x86).
     36
     37As the Cmm code generator cannot reorder reads/writes around prim calls (i.e. `CallishMachOp`s) the `memory_order_seq_cst` semantics should be preserved, as long as the backend outputs a memory barrier to prevent CPU speculation.
    3438
    3539== Ordering of non-atomic operations
    3640
    37 The memory ordering of non-atomic operations surrounding an atomic operation correspond to the `memory_order_seq_cst` ordering specified for C11, which provides the strongest ordering guarantee.
     41We'll use sequential consistency, which corresponds to the C++0x/C1x `memory_order_seq_cst`, Java `volatile`, and the gcc-compatible `__sync_*` builtins. This is the strongest consistency guarantee. We can provide weaker guarantees in the future, if needed.