Da Zheng, le Wed 23 Dec 2009 19:17:43 +0800, a écrit : > If we declare all shared variables are volatile, it certainly work but there > is serious performance penalty here. I think that's why people prefer to use > spin_lock or mutex to protect other variables.
Yes. > I think the difference in the SMP case is that there may be cache coherence > problem Yes, exactly. > but I believe most SMP handle it by hardware automatically and software > doesn't need to do anything. That would be too expensive and wouldn't scale. That's what i386 does, and it doesn't scale. Nowadays x86 does out-of order stores which permits much more efficient hardware cache coherency. most other processors have already been doing it that way from the beginning of course :) > Is there anything else we should worry about? Ordering. See /usr/src/linux/Documentation/memory-barriers.txt > 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). > In this case, either compilers or the machine cannot reorder instructions any > way. They wouldn't because they provide sequential coherency, indeed > 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. > >> 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. > No instructions will be generated to prevent out-of-order execution of > instructions in the processor? Yes. Asm statements really _only_ emit what you put in the string. > Memory barrier at the SMP level is to handle the cache coherence problem? Yes. Samuel