All CPUs commit in order and except precisely, because most other options are insane, or would drive you to it. However: single thread commit order =/= observability order.
Observability order of memory operations --- which are the only operations that matter --- are governed by the memory consistency model of the architecture.
x86 has what's generally referred to as strong ordering on memory operations.
On x86, part of it means that stores from the same core cannot be observed out of order from each other, nor can loads.
So assuming the compiler does not move the `tail++` up, or move the assignment out of the if-statement (both of which are achieved by marking them `volatile`), the code should actually work on x86.
The `tail++` change cannot be observed before the write to the queue and the reading from the queue cannot be observed before the reading of the `tail` and `head` variables.
On RISC-V and Arm, you need more as they have substantially weaker memory consistency. The RISC-V specs have some examples of interesting outcomes you can have. Some of it involves time-travel.
But in the end: yes the reordering done by the CPU is the issue. The compiler can and does reorder stuff when it thinks that it'll unlock more instruction-level parallelism, but no amount of volatile is going to make that queue universally usable on RISC-V. No matter what the compiler does. Even perfectly preserving the single-thread semantics of the code, not reordering a single instruction, the CPU can move stuff around in terms of observability.
The alternative is that the compiler inserts a barrier/fence after every instruction.
There are trade-offs. Poorly written code for x86 can absolutely tank performance because of ordering violations requiring code to be replayed, though that is sometimes a problem in even weaker consistency models as well.
This is why I switched to Helix. The configuration is practically non-existent, and it has default configs for all the language servers I could ever want to interact with. I just put the language server binary in my path and I'm ready to go with autocomplete and all the other features.
I never got the impression that the developers had an attitude. The discussion I've seen has been mostly people making demands or saying Helix will fail if it doesn't support AI tool integration right now, but none of the devs are interested in using that kind of tooling with Helix, so they don't implement it.
When they have poked fun at someone, it has been because that someone is very quick to demand the feature, but unwilling to submit a PR.
There is an open PR for getting copilot support, though it's currently just a hotfix and likely won't be accepted into core. You can still patch your own version and compile it.
Observability order of memory operations --- which are the only operations that matter --- are governed by the memory consistency model of the architecture. x86 has what's generally referred to as strong ordering on memory operations.
On x86, part of it means that stores from the same core cannot be observed out of order from each other, nor can loads.
So assuming the compiler does not move the `tail++` up, or move the assignment out of the if-statement (both of which are achieved by marking them `volatile`), the code should actually work on x86. The `tail++` change cannot be observed before the write to the queue and the reading from the queue cannot be observed before the reading of the `tail` and `head` variables.
On RISC-V and Arm, you need more as they have substantially weaker memory consistency. The RISC-V specs have some examples of interesting outcomes you can have. Some of it involves time-travel.
But in the end: yes the reordering done by the CPU is the issue. The compiler can and does reorder stuff when it thinks that it'll unlock more instruction-level parallelism, but no amount of volatile is going to make that queue universally usable on RISC-V. No matter what the compiler does. Even perfectly preserving the single-thread semantics of the code, not reordering a single instruction, the CPU can move stuff around in terms of observability. The alternative is that the compiler inserts a barrier/fence after every instruction.
There are trade-offs. Poorly written code for x86 can absolutely tank performance because of ordering violations requiring code to be replayed, though that is sometimes a problem in even weaker consistency models as well.