4 ms·

The memory model of the ISA != the memory model of your code. C has a memory model and any correct C code is compiled to the correct ARM assembly. It's only rea

The memory model of the ISA != the memory model of your code. C has a memory model and any correct C code is compiled to the correct ARM assembly. It's only really an issue if you are translating over x86 assembly, and then you probably have lots of other issues to worry about.

chrisseaton 6y ago
If you’re the one implementing the language’s memory model then it’s your problem isn’t it? If you’re generating the machine code then it’s your problem isn’t it? If you’re writing lock-fee code that doesn’t use the C memory model then it’s your problem isn’t it? > then you probably have lots of other issues to worry about Yes, yes we do.
dan-robertson 6y ago
Arm provides different models for consistency of changes to memory from different cores/cpus to Intel. Concurrent (typically lock-free) code may be relying on intel’s behaviour
gpderetta 6y ago
a lot of code (especially old code bases) does not actually target the c11 memory model but just happens to work on x86. A lot of code that targets the c11 memory model but primarily targetting x86, still assumes cheap (or free) release/acquire memory barriers (although admittedly arm64 should have reasonably cheap release/acquire and Apple could make them as cheap as they want).
0x0 6y ago
Does C really have a memory model for multithreaded applications? I tried googling but could only find references to C++11. Also, failing to adhere to a memory model is one of those tricky things where things seem to work alright on architectures with a strong SMP coherency. But then it all breaks down and you end up chasing heisenbugs all over the place when those assumptions no longer hold. It's not easy to prove a lack of race condition bugs. You usually don't get a compiler error if you forget to mark things volatile, forget memory barriers or forget proper locking.

chrisseaton 6y ago

If you’re the one implementing the language’s memory model then it’s your problem isn’t it? If you’re generating the machine code then it’s your problem isn’t it? If you’re writing lock-fee code that doesn’t use the C memory model then it’s your problem isn’t it? > then you probably have lots of other issues to worry about Yes, yes we do.

dan-robertson 6y ago

Arm provides different models for consistency of changes to memory from different cores/cpus to Intel. Concurrent (typically lock-free) code may be relying on intel’s behaviour

gpderetta 6y ago

a lot of code (especially old code bases) does not actually target the c11 memory model but just happens to work on x86. A lot of code that targets the c11 memory model but primarily targetting x86, still assumes cheap (or free) release/acquire memory barriers (although admittedly arm64 should have reasonably cheap release/acquire and Apple could make them as cheap as they want).

0x0 6y ago

Does C really have a memory model for multithreaded applications? I tried googling but could only find references to C++11. Also, failing to adhere to a memory model is one of those tricky things where things seem to work alright on architectures with a strong SMP coherency. But then it all breaks down and you end up chasing heisenbugs all over the place when those assumptions no longer hold. It's not easy to prove a lack of race condition bugs. You usually don't get a compiler error if you forget to mark things volatile, forget memory barriers or forget proper locking.