mumblingdrunk
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.
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.
In my very limited experience, most people don't learn new stuff until they're forced to; either by their employer, by their university, or by needing to learn it for something they want to accomplish. This is why you'll have self-taught developers go for years using strings as enums, linear-searching in huge sorted arrays, because it works and why would you seek out something else? I think the solution is to introduce more software development in EE education; forcibly expose them to it. My EE bachelor's degree contained a whopping ONE class that was focused entirely on Python programming. The rest just used cobbled-together C code for microcontrollers, or arcane languages with dumb IDEs for PLCs.
I'll take your hint on Vivado, thanks!
All the companies that produce anything invent their own language for the thing and write their own compiler for it. These compilers are clearly not written by compiler experts.
I don't blame EEs for building bad software. They weren't trained to do it and aren't paid to do it. I blame the "if it works, it works" culture that the industry seems to have. Never go back to refine anything, just keep pushing more plugins, more software; create a patchwork of programs until you get the job done.
MRSs would enable much more of the formal verification parts to be generated.
While you're there, take a stroll around Bletchley Park as well. Last time I checked, you get a discount when visiting both, and they're right next to each other.
You're adding other claims and statements that make me question if you actually understand the thing you are criticising.
And no, memory safety is a huge deal, it is just that the borrow checker cannot verify the soundness of certain code, meaning you have to provide the guarantees normally given to you outside 'unsafe' blocks.
Yes, this means that a few data structures require 'unsafe', but you should be creating safe wrappers around these structures; 'unsafe' won't propagate up your code and poison everything.
Boxes, cells, arcs, etc. exist for different purposes and if you'd take two hours to actually read about them and their uses, you'd understand why they exist.