2 ms·

For another empirical example, the linux kernel requires marking all address-dependent accesses via rcu_dereference or LOAD_ONCE. In particular rcu_dereference

For another empirical example, the linux kernel requires marking all address-dependent accesses via rcu_dereference or LOAD_ONCE. In particular rcu_dereference has an entire section on all the restrictions on what you can do with the result to prevent the compiler from messing with it. For example only deal with pointers, avoid cancellations, etc. Only the things that have been empirically been shown to be safe are allowed. Of course "do what gcc x.y does" is not a good spec so the standard tried to specify exactly the behavior of consume is, but it failed to be implementable.

ajross 3y ago
> For another empirical example, the linux kernel requires marking all address-dependent accesses via rcu_dereference Right. Solely so it can support DEC Alpha! I'm not saying data dependence has never been an ordering constraint, I'm saying it was only an ordering constraint on an ancient platform that thus doesn't belong in the standard. And by extension I'm saying that you people talking about standards instead of hardware are needlessly (frankly: deliberately and obfuscatorily) obscuring that clear truth.
- gpderetta 3y ago
  Absolutely not solely for DEC Alpha; From the source [1]: You must use one of the rcu_dereference() family of primitives to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU will complain. Worse yet, your code can see random memory-corruption bugs due to games that compilers and DEC Alpha can play. Without one of the rcu_dereference() primitives, compilers can reload the value, and won't your code have fun with two different values for a single pointer! Without rcu_dereference(), DEC Alpha can load a pointer, dereference that pointer, and return data preceding initialization that preceded the store of the pointer. The whole document then goes in great details on the all the ways the compiler can screw you over. If the kernel were to drop Alpha support tomorrow, rcu_dereference and all the warnings would still be relevant. Similarly, if only x86, SPARC and Alpha existed, memory order relaxed, acquire/release and seq-cst would be sufficient. consume only exists to cater to architectures with memory models stronger than Alpha but weaker than TSO. [1]https://www.kernel.org/doc/Documentation/RCU/rcu_dereference.txt https://www.kernel.org/doc/Documentation/RCU/rcu_dereference...
- reitzensteinm 3y ago
  Your focus on hardware misses the big picture. Atomic operations also restrict what the compiler can reorder. Just because the simplest translation to assembly yields a data dependency on ARM et al doesn't mean the compiler is obligated to honor that. The focus on standards is precisely because that's the only contract the compiler gives you. If you write code expecting to also get your target architecture's guarantees for free, you're writing software that is at best only incidentally correct until the next compiler update. I look around this thread and I don't see a group of people trolling you - I genuinely think you're missing the point.

ajross 3y ago

> For another empirical example, the linux kernel requires marking all address-dependent accesses via rcu_dereference Right. Solely so it can support DEC Alpha! I'm not saying data dependence has never been an ordering constraint, I'm saying it was only an ordering constraint on an ancient platform that thus doesn't belong in the standard. And by extension I'm saying that you people talking about standards instead of hardware are needlessly (frankly: deliberately and obfuscatorily) obscuring that clear truth.

gpderetta 3y ago
Absolutely not solely for DEC Alpha; From the source [1]: You must use one of the rcu_dereference() family of primitives to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU will complain. Worse yet, your code can see random memory-corruption bugs due to games that compilers and DEC Alpha can play. Without one of the rcu_dereference() primitives, compilers can reload the value, and won't your code have fun with two different values for a single pointer! Without rcu_dereference(), DEC Alpha can load a pointer, dereference that pointer, and return data preceding initialization that preceded the store of the pointer. The whole document then goes in great details on the all the ways the compiler can screw you over. If the kernel were to drop Alpha support tomorrow, rcu_dereference and all the warnings would still be relevant. Similarly, if only x86, SPARC and Alpha existed, memory order relaxed, acquire/release and seq-cst would be sufficient. consume only exists to cater to architectures with memory models stronger than Alpha but weaker than TSO. [1]https://www.kernel.org/doc/Documentation/RCU/rcu_dereference.txt https://www.kernel.org/doc/Documentation/RCU/rcu_dereference...
reitzensteinm 3y ago
Your focus on hardware misses the big picture. Atomic operations also restrict what the compiler can reorder. Just because the simplest translation to assembly yields a data dependency on ARM et al doesn't mean the compiler is obligated to honor that. The focus on standards is precisely because that's the only contract the compiler gives you. If you write code expecting to also get your target architecture's guarantees for free, you're writing software that is at best only incidentally correct until the next compiler update. I look around this thread and I don't see a group of people trolling you - I genuinely think you're missing the point.