Re: What would it take....

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