3 ms·

> As high-performance code demands faster-and-faster systems, the more-and-more relaxed our systems will become. Acquire/release is quickly becoming the standar

> As high-performance code demands faster-and-faster systems, the more-and-more relaxed our systems will become. Acquire/release is quickly becoming the standard model. Linux relies heavily on performant RCU for scalability, which a pure acquire/release SW programming model can't support.

dragontamer 7y ago
There must be some kind of communication error going on. I don't know much about RCU, so I just pulled up this webpage: https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt In it is: > The rcu_read_lock() and rcu_read_unlock() primitive read-acquire and release a global reader-writer lock. Seems like RCU-operations in the Linux kernel are defined in acquire-barrier and release-barrier terms. I heard a while ago that RCU could be discussed in terms of release-consume semantics (which are slightly faster but harder to understand...) but very few people understand release-consume. As such, release-acquire is probably the memory model of the future. I'm not really aware of anything aside from: Fully Relaxed (unordered), the obscure release-consume, release-acquire, and finally sequentially consistent (too slow for modern systems) --------- Are you perhaps confusing "acquire-release" semantics (which is a memory-barrier / cache coherence principle) with spinlocks perchance? Acquire-release seems to be the "Fastest-practical" memory consistency model. (Since Relaxed doesn't work, and release-consume is too confusing) For more info on acquire-release, Preshing's blogposts are great: https://preshing.com/20130922/acquire-and-release-fences/ https://preshing.com/20130922/acquire-and-release-fences/
- jabl 7y ago
  > I'm not really aware of anything aside from: Fully Relaxed (unordered), the obscure release-consume, release-acquire, and finally sequentially consistent (too slow for modern systems) What about Total Store Ordering (TSO), which is what e.g. the obscure and rare x86(-64) architecture implements (and SPARC as well)?
  - gpderetta 7y ago
    In TSO every store is a release and every load is a acquire, so it maps very efficiently to the acquire/release model.
    - jabl 7y ago
      Sure, since it's a stronger model, so code which works on weaker acquire/release hw will work on TSO hw as well. You might as well say that sequential consistency maps very efficiently to a acquire/release model too in the same way.
      - gpderetta 7y ago
        Isn't TSO the closest practical implementation to a acquire/release model? What are the practical differences? I know that TSO allows more easily to recover sequential consistency with additional barriers (Intel strengthened their original memory model to TSO for this reason).
        jabl 7y ago
        No, acquire/release is a much weaker model than TSO. TSO is basically sequential consistency (SEQCST) + a store buffer. I.e. stores don't go immediately to main memory, but rather via a store buffer. Loads first peek into the store buffer of the local CPU core before going to memory. The practical effect is that in contrast to SEQCST stores may be reordered after loads ("store->load" reordering more formally). Acquire-release consistency allows many more reorderings in addition to store->load (load->load, load->store, store->store). For more info see e.g. Table 5 in http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2...
  - atq2119 7y ago
    Keep in mind that even when the underlying hardware implements TSO, what programming languages expose is basically the release/acquire model of memory semantics. This means that as a programmer, you still have to code against the release/acquire model because the compiler may reorder your memory accesses. Having TSO in hardware is still helpful though, because it means the compiler has to emit fewer explicit barrier instructions at the end. That is, the barriers that you do have in your original code end up being a little bit cheaper (at the cost of having an overall more complex hardware architecture).

dragontamer 7y ago

There must be some kind of communication error going on. I don't know much about RCU, so I just pulled up this webpage: https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt In it is: > The rcu_read_lock() and rcu_read_unlock() primitive read-acquire and release a global reader-writer lock. Seems like RCU-operations in the Linux kernel are defined in acquire-barrier and release-barrier terms. I heard a while ago that RCU could be discussed in terms of release-consume semantics (which are slightly faster but harder to understand...) but very few people understand release-consume. As such, release-acquire is probably the memory model of the future. I'm not really aware of anything aside from: Fully Relaxed (unordered), the obscure release-consume, release-acquire, and finally sequentially consistent (too slow for modern systems) --------- Are you perhaps confusing "acquire-release" semantics (which is a memory-barrier / cache coherence principle) with spinlocks perchance? Acquire-release seems to be the "Fastest-practical" memory consistency model. (Since Relaxed doesn't work, and release-consume is too confusing) For more info on acquire-release, Preshing's blogposts are great: https://preshing.com/20130922/acquire-and-release-fences/ https://preshing.com/20130922/acquire-and-release-fences/

jabl 7y ago
> I'm not really aware of anything aside from: Fully Relaxed (unordered), the obscure release-consume, release-acquire, and finally sequentially consistent (too slow for modern systems) What about Total Store Ordering (TSO), which is what e.g. the obscure and rare x86(-64) architecture implements (and SPARC as well)?
- gpderetta 7y ago
  In TSO every store is a release and every load is a acquire, so it maps very efficiently to the acquire/release model.
  - jabl 7y ago
    Sure, since it's a stronger model, so code which works on weaker acquire/release hw will work on TSO hw as well. You might as well say that sequential consistency maps very efficiently to a acquire/release model too in the same way.
    - gpderetta 7y ago
      Isn't TSO the closest practical implementation to a acquire/release model? What are the practical differences? I know that TSO allows more easily to recover sequential consistency with additional barriers (Intel strengthened their original memory model to TSO for this reason).
      - jabl 7y ago
        No, acquire/release is a much weaker model than TSO. TSO is basically sequential consistency (SEQCST) + a store buffer. I.e. stores don't go immediately to main memory, but rather via a store buffer. Loads first peek into the store buffer of the local CPU core before going to memory. The practical effect is that in contrast to SEQCST stores may be reordered after loads ("store->load" reordering more formally). Acquire-release consistency allows many more reorderings in addition to store->load (load->load, load->store, store->store). For more info see e.g. Table 5 in http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2...
- atq2119 7y ago
  Keep in mind that even when the underlying hardware implements TSO, what programming languages expose is basically the release/acquire model of memory semantics. This means that as a programmer, you still have to code against the release/acquire model because the compiler may reorder your memory accesses. Having TSO in hardware is still helpful though, because it means the compiler has to emit fewer explicit barrier instructions at the end. That is, the barriers that you do have in your original code end up being a little bit cheaper (at the cost of having an overall more complex hardware architecture).