[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What would it take....

From: Da Zheng
Subject: Re: What would it take....
Date: Wed, 23 Dec 2009 19:17:43 +0800
User-agent: Thunderbird (Macintosh/20090812)


Samuel Thibault wrote:
> Da Zheng, le Wed 23 Dec 2009 16:46:34 +0800, a écrit :
>>> If you use volatile, the compiler won't
>>> optimise instructions so it would "work" too ; note however that it's
>>> not SMP safe (it may even not be premption-safe, depending on which
>>> instruction the compiler eventually uses).
>> We don't need both? If there is only volatile, instructions might be 
>> executed out of order and compilers might also reorder instructions.
> Volatile prevents from compiler reorder. Out of order execution doesn't
> appear at the API level in the UP case, the processor is supposed to
> provide a coherent view to the programmer. SMP is a completely different
> story of course. Preemption is another story depending on the
> architecture and the instructions that get emited (e.g. memory
> incrementation ins vs load+inc+store ins).
Volatile can only prevent compilers reordering instructions that have the 
volatile variable involved. 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.

I think the difference in the SMP case is that there may be cache coherence 
problem but I believe most SMP handle it by hardware automatically and software 
doesn't need to do anything. Is there anything else we should worry about?

The reason that we need to protect a shared variable is either threads run on 
multiprocessors or the execution of a thread is preempted by the kernel or 
another thread. As you said, there are some kind of problems in the both cases. 
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. In this case, either 
compilers or the machine cannot reorder instructions any way.
Unless you mean different preemption here.
>> As far as I see, spin_lock always uses "volatile" keyword to define 
>> spin_lock variables and there is "memory" in the list of clobbered registers 
>> of the inline assembly code.
> It uses volatile because __spin_lock_locked doesn't do anything
> particular and just reads the variable without any memory barrier.
OK, I see.
>> 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". No instructions will be generated to prevent out-of-order 
execution of instructions in the processor?

Memory barrier at the SMP level is to handle the cache coherence problem?

Zheng Da

reply via email to

[Prev in Thread] Current Thread [Next in Thread]