Hi Jason,   today not even assembler is executed as written, let's just name two features: instruction reordering, speculative execution.   But for programming we still assume that  - the visible effects of our program are the same as written. For it there is the abstract machine in C++,  - the performance of the program is not totally worse than written. We (at least) expect the optimizers and the execution hardware to not pessimize the code into another O notation category.   Everything else to fine-control, what the system does, is difficult to achieve even on specified platforms with a specific compiler.   The volatile keyword was (and is) always a clunky means. Non volatile-accessing instructions could be moved before and after volatile-accessing ones. Memory barriers for other CPU cores to communicate with other threads running there had to (depending on the platform and the compiler) be inserted in addition to declaring variables as volatile. You could not distinguish different "volatile streams" for the ordering. Even the compilers, which supported memory fences, did not distinguish between read and write barriers for volatile.   For getting all this right, you had to be a specialist and careful. But as specialist you wanted to have a good tool with possibility for finegrained control.     If the aim is to have certain points in the program, where no instruction ordering may be made from before or after, e.g. after every line or at certain checkpoints, if the aim is to be able to read the contents of certain variables at certain locations in the program, because they are stored in a specific memory region, then this can be achieved through the compiller, optimizer, linker, debugger.   Perhaps volatile for those use cases could be/have been saved by defining those use cases, listing the expected result and whether volatile is a good method/expression of the intention to do it.   Best, Sebastian