
    <para>
        In these operation definitions:
    </para>

    <para>
      <itemizedlist>
        <listitem>
            An <code>A</code> refers to one of the atomic types.
        </listitem>

        <listitem>
            A <code>C</code> refers to its corresponding non-atomic type.
        </listitem>

        <listitem>
            An <code>M</code> refers to the type of the other 
            argument for arithmetic operations. For atomic 
            integer types, <code>M</code> is <code>C</code>.
        </listitem>

        <listitem>
            The functions not ending in explicit have the same semantics as the corresponding
            explicit function with <constant>memory_order_seq_cst</constant> 
            for the <code>memory_order</code> argument.
        </listitem>

        <listitem>
            The functions that do not have <code>memory_scope</code> 
            argument have the same semantics as 
            the corresponding functions with the <code>memory_scope</code> argument set to
            <constant>memory_scope_device</constant>.
        </listitem>
      </itemizedlist>
    </para>

    <para>
        NOTE: With fine-grained system SVM, sharing 
        happens at the granularity of individual loads 
        and stores anywhere in host memory. Memory 
        consistency is always guaranteed at 
        synchronization points, but to obtain finer 
        control over consistency, the OpenCL atomics 
        functions may be used to ensure that the updates 
        to individual data values made by one unit of 
        execution are visible to other execution units. 
        In particular, when a host thread needs fine 
        control over the consistency of memory that is 
        shared with one or more OpenCL devices, it must 
        use atomic and fence operations that are 
        compatible with the C11 atomic operations.
    </para>

    <para>
        We can't require C11 atomics since host programs can 
        be implemented in other programming languages and 
        versions of C or C++, but we do require that the host 
        programs use atomics and that those atomics be compatible 
        with those in C11.
    </para>

    <bridgehead>Restrictions</bridgehead>

    <para>
        All operations on atomic types must be performed using the built-in atomic 
        functions. C11 and C++11 support operators on atomic types. OpenCL C does not 
        support operators with atomic types. Using atomic types with operators should result in a 
        compilation error.
    </para>

    <para>
        The <type>atomic_bool</type>, <type>atomic_char</type>, 
        <type>atomic_uchar</type>, <type>atomic_short</type>, 
        <type>atomic_ushort</type>, <type>atomic_intmax_t</type> 
        and <type>atomic_uintmax_t</type> types are not 
        supported by OpenCL C.
    </para>

    <para>
        OpenCL C requires that the built-in atomic functions on 
        atomic types are lock-free.
    </para>

    <para>
        The <code>_Atomic</code> type specifier and <code>_Atomic</code> 
        type qualifier are not supported by OpenCL C.
    </para>

    <para>
        The behavior of atomic operations where pointer 
        arguments to the atomic functions refers 
        to an atomic type in the private address space is undefined.
    </para>

 <!-- 28-Oct-2015, Ext ver 2.1 rev 10; C lang ver 2.0 rev 30 -->