Samuel Thibault wrote: >> Is there anything else we should worry about? > > Ordering. See /usr/src/linux/Documentation/memory-barriers.txt It's a long file. There are a lot to study:) > >> Then the use of volatile is very limited and the only case I can think of is >> something like signal handling where there is long jump. > > There's also memory-mapped hardware registers (for which the OS has to > disable processor cache too, of course). You mean memory-mapped IO? Yes, it's another case. >> Unless you mean different preemption here. > > I mean that, but remember that incrementing a variable may be done by > load then inc, then store. If a signal happens in between and jumps to > another thread incrementing the same variable, you've lost. OK, I see. Does it mean all machines have to provide at least one instruction that can modify variables in memory direct? so we can implement spin_lock or something similar. > >>>> Doesn't "memory" mean memory barrier? >>> Depends on what you mean by "memory barrier". It's a memory barrier only >>> for the compiler, by telling it that the asm statement modified memory >>> in a way beyond the other asm constraints. It doesn't emit an >>> instruction to ensure memory barrier at the SMP level, for instance. >> I believe "memory" can also prevent GCC reordering some >> instructions. For example, the instructions before "memory" cannot >> be reordered and be executed after "memory". > > They can if they don't touch memory for instance I see. I didn't know that.
Zheng Da
