Re: What would it take....

[Da Zheng]

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