> No, volatile is not for multi-threading, this is an old misconception: https://software.intel.com/en-us/blogs/2007/11/30/volatile-a....

No, downvote arrow is only after you read the comment, not before. Can you show where I wrote "multi-threaded" in my comment?

"shared memory" and "other process" quite hints at the frequent use of volatile where fences and other synchronization primitives are needed. (Note: I didn't down-vote anything)

Sorry assumed it was you. It was the only comment and a downvote.

Shared memory and processes is a different beast than just threads in same process. Memory was mmap-ed between the two OS procs. Didn't use locks in that part of code for a list of reasons..., and memory write order didn't matter as much (so didn't see an immediate need for memory fences, but someone below suggested those might work to fix compiler optimizing out accesses when nor in debug mode).

Not sure what hinted at frequent use of volatile, it was the only use in 10 years. That is what made it memorable.

Wasn't me either. Can't downvote yet. :)

Did some more research. Compilers have their own intrinsics that only affect the code generated (in addition to the processor ones). VS has _ReadBarrier, _WriteBarrier and _ReadWriteBarrier while GCC has asm volatile("" ::: "memory"); to prevent reordering optimizations.

There really isn't any difference between multithread with common processes memory and multiprocess with mmaped shared memory. Both have mutliple threads accessing the same physical memory but in one case the OS made the memory common and the other you made the memory common.

BTW, when I say multithreaded I'm talking real threads and not light/green/cooperative/fake/whatever threads.

Thanks for doing more research. Did you get the idea there are two separate issues at hand -- 1) compiler optimizes memory access away because to its logic it seems the value is not written anywhere in that process. Say it could use a register instead if memory read. This is the effect I was seeing. 2) Compiler inserts the memory read instruction, but depending on the processor, at runtime, some of the writes will not show up at all, or be reorded. In this case running program on different CPU might make it appear to work correctly. I think there is a slight difference between the two from reading about back then. Can the first issue be fixed with a memory barrier?

Yes, you are correct that there are two issues. But solving 2 may solve 1 automatically or just need the compiler barrier intrinsics in the same spots as the processor barrier intrinsics.

And yes, the first issue can be fixed with memory barriers. If you put a compiler+processor read barrier in front of the first line that reads the shared variable the compiler will re-read it from memory back into a register. After that it will use the register as to not kill performance until it hits the barrier again.

So you think wrapping every single access to that shared memory structure in barriers would do the trick? I should dig out that code and try, I am curious now. But that would be kind of an large change. Now the volatile modifier is in one place only -- where data is defined not when it is accessed.

If you do it correctly it should work. I'm curious if that code is running on a multi core (or even hyperthreaded) CPU.