4 ms·

A barrier, of any kind, makes no difference here. Barriers only influence the order in which events become visible if and when they DO become visible. Barrier

A barrier, of any kind, makes no difference here. Barriers only influence the order in which events become visible if and when they DO become visible. Barriers say nothing about whether or not events actually do become visible; and it may be that they never do (if the necessary magic is not performed, etc). You mention an atomic increment. I don't see atomic increments this in the C11 code, but I'm not up to speed with that version of the specification. (Note that an atomic increment will solve the write-side problem, but not the read-side problem. The reader must still use a read barrier; but if there's an implicit full barrier, then that's being done.)

gpderetta 5y ago
The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value. A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time Edit: that's true for C11 _Atomic as well (I had to double check), I.e. x++ if x is an _Atomic int is both atomic and seqcst
- MaxGanzII 5y ago
  > The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value. Firstly, if the writer has used no barriers, writes can emerge in any order (and may never emerge at all, anyway, even if barriers were used). Secondly, if the reader has not used barriers, then even if writes have been written in some given order, the reader will by no means observe that order. > A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time A fence does NOT guarantee this. A fence controls and only only controls order of events. It has NO influence on whether events actually emerge. An atomic operation does, but this only solves the write-side of the problem; the reader still needs to issue a read barrier to guarantee seeing atomically written values.
  - gpderetta 5y ago
    Sure but inc in addition to the fence also issues the required reads and writes.
    - MaxGanzII 5y ago
      An atomic write will need to be issued, and on the face of it, that C11 code is not issuing an atomic write. I could be wrong, but I would expect a particular function or macro to be used for an atomic write, and when it is not, you have normal writes.
      - gpderetta 5y ago
        So all operations on _Atomic variables in C11 are implicitly atomic and sequentially consistent, which for an RMW like inc imply release plus acquire.
        MaxGanzII 5y ago
        > So all operations on _Atomic variables in C11 are implicitly atomic I may be wrong, but I would be shocked if this was so. I think you may be mixing up non-tearing writes as opposed to atomic writes, which are performed using either cache-line locking (Intel) or exclusive reservation granules (everyone else) and as such require the employment of a specific mechanism to achieve (typically a macro or function, which leads to the use of the particular special instructions for atomic writes). The overhead of an atomic write is very large, and it is often not needed. It would make no sense for every write (to an _Atomic type) to be atomic.
        gpderetta 5y ago
        The standard does guarantee that all the operations on _Atomic variables are indeed atomic and, by default, sequentially consistent. Standard library functions like atomic_load can be used to specify more relaxed ordering. As per intel docs, all aligned stores and loads are atomic with additional release and acquire semantics. XCHG (which is somewhat expensive) is used for SC stores, but plain loads still suffice for SC loads. On other architectures load and stores are usually at least atomic, although with only relaxed ordering semantics. Normally non-tearing + cache coherence is all that is required for relaxed atomic load/stores. You are confusing with general RMW that require specialized instructions on intel or ll/sc on RISCs (although ARM did add a bunch of specialized atomic instructions as well). To be pedantic, as far as I know, Intel doesn't lock the cacheline in any special way during an atomic RMW, it simply delays the read until all preceding stores have been flushed from the store buffer, then, if it has successfully acquired the line in exclusive mode, executes the load+store within whatever minimum exclusive cache hold period guaranteed by the coherence protocol. Acquiring a cacheline in exclusive mode is not specific to atomic RMWs but applies to any store and it is not really a lock as it can be taken away at any moment (i.e. the cc arbiter guarantees forward progress of the system as whole).

gpderetta 5y ago

The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value. A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time Edit: that's true for C11 _Atomic as well (I had to double check), I.e. x++ if x is an _Atomic int is both atomic and seqcst

MaxGanzII 5y ago
> The fact that another thread sees the incremented value implies that that thread will see all stores that happened-before that incremented value. Firstly, if the writer has used no barriers, writes can emerge in any order (and may never emerge at all, anyway, even if barriers were used). Secondly, if the reader has not used barriers, then even if writes have been written in some given order, the reader will by no means observe that order. > A fence or atomic operation guarantee that a store will be visible globally in a finite amount of time A fence does NOT guarantee this. A fence controls and only only controls order of events. It has NO influence on whether events actually emerge. An atomic operation does, but this only solves the write-side of the problem; the reader still needs to issue a read barrier to guarantee seeing atomically written values.
- gpderetta 5y ago
  Sure but inc in addition to the fence also issues the required reads and writes.
  - MaxGanzII 5y ago
    An atomic write will need to be issued, and on the face of it, that C11 code is not issuing an atomic write. I could be wrong, but I would expect a particular function or macro to be used for an atomic write, and when it is not, you have normal writes.
    - gpderetta 5y ago
      So all operations on _Atomic variables in C11 are implicitly atomic and sequentially consistent, which for an RMW like inc imply release plus acquire.
      - MaxGanzII 5y ago
        > So all operations on _Atomic variables in C11 are implicitly atomic I may be wrong, but I would be shocked if this was so. I think you may be mixing up non-tearing writes as opposed to atomic writes, which are performed using either cache-line locking (Intel) or exclusive reservation granules (everyone else) and as such require the employment of a specific mechanism to achieve (typically a macro or function, which leads to the use of the particular special instructions for atomic writes). The overhead of an atomic write is very large, and it is often not needed. It would make no sense for every write (to an _Atomic type) to be atomic.
        gpderetta 5y ago
        The standard does guarantee that all the operations on _Atomic variables are indeed atomic and, by default, sequentially consistent. Standard library functions like atomic_load can be used to specify more relaxed ordering. As per intel docs, all aligned stores and loads are atomic with additional release and acquire semantics. XCHG (which is somewhat expensive) is used for SC stores, but plain loads still suffice for SC loads. On other architectures load and stores are usually at least atomic, although with only relaxed ordering semantics. Normally non-tearing + cache coherence is all that is required for relaxed atomic load/stores. You are confusing with general RMW that require specialized instructions on intel or ll/sc on RISCs (although ARM did add a bunch of specialized atomic instructions as well). To be pedantic, as far as I know, Intel doesn't lock the cacheline in any special way during an atomic RMW, it simply delays the read until all preceding stores have been flushed from the store buffer, then, if it has successfully acquired the line in exclusive mode, executes the load+store within whatever minimum exclusive cache hold period guaranteed by the coherence protocol. Acquiring a cacheline in exclusive mode is not specific to atomic RMWs but applies to any store and it is not really a lock as it can be taken away at any moment (i.e. the cc arbiter guarantees forward progress of the system as whole).