Re: What would it take....

[Samuel Thibault]

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