> On Mar 5, 2015, at 4:34 PM, James Bottomley
> <james.bottom...@hansenpartnership.com> wrote:
>
> On Wed, 2015-03-04 at 18:30 -0800, Andrew Fish wrote:
>>> On Mar 4, 2015, at 5:34 PM, Chen Fan <chen.fan.f...@cn.fujitsu.com> wrote:
>>>
>>> Hi Jeff,
>>>
>>> Thanks for your explanation, I didn't encounter any issue if leaving it
>>> there.
>>>
>>> I just think if use Volatile qualifier may cause the problem of
>>> performance. because
>>> access the value need to copy the address value from main memory to cpu
>>> cache
>>> each time and not use the cache.
>>> and IIRC, in a shared memory multiprocessor system, the cache coherence may
>>> keep the consistency of shared resource data in each processor local
>>> caches.
>>> if the value is updated by one processor in local cache, the copy of
>>> memory data in
>>> other processor caches will be marked as invalid. and then other
>>> processors read the
>>> value will access from the main memory.
>>> if I misunderstand, please correct me. :)
>>>
>>
>> Correction!
>>
>> Volatile in C has nothing to do with hardware and caching. It has to
>> do with the abstract memory model for the compiler as defined by the C
>> standard. The more aggressive the compiler optimizes the code the more
>> you are exposed to potential issues. If the compiler knows about all
>> the code in the program that accesses a variable it can assume that
>> memory location will only be changed by the compiler, and make
>> optimizations (like storing a pointer in a register).
>
> Just to say this in a stronger way: using a volatile keyword on data
> usually indicates a mistake in the program.
+1 as too many people try to use volatile for thread sync, and thank is a bad
idea!
> The reason is that all
> locking primitives are memory barriers (a memory barrier to a compiler
> means that all externally stored variables that are being housed in
> temporary storage are placed in stable storage on crossing a memory
> barrier). The only reason you would need a volatile primitive in SMP
> code is if the variable is being accessed without locking, so the first
> question should be "where's the lock that protects this data?".
100% agree. The locks are memory barriers, but you are still exposed to the C
memory model between the locks (see example).
So it kind of depends how much work you are doing between the lock and unlock.
You could argue doing a lot of work between the locks is a bad design, but …
I’m guessing its probably just over specification of the volatile. I know I’ve
had my vendors memory test stripped from my executable since it tried to write
to address 0. You get a little paranoid about NOT using volatile if you write
enough firmware.
Thanks,
Andrew Fish
~/work/Compiler>cat volatile.c
int
main (int argc, char **argv)
{
int *i = (int *)0xFFFFFFF0;
int j;
__asm__ __volatile__ ("":::"memory");
for (j=0; (j < 100) && (*i != 0); j++);
__asm__ __volatile__ ("":::"memory");
return 0;
}
~/work/Compiler>clang -S -O3 volatile.c
~/work/Compiler>cat volatile.S
.section __TEXT,__text,regular,pure_instructions
.globl _main
.align 4, 0x90
_main: ## @main
.cfi_startproc
## BB#0: ## %.critedge.split
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
## InlineAsm Start
## InlineAsm End
## InlineAsm Start
## InlineAsm End
xorl %eax, %eax
popq %rbp
retq
.cfi_endproc
.subsections_via_symbols
~/work/Compiler>
Making i volatile changes it all:
~/work/Compiler>cat volatile.S
.section __TEXT,__text,regular,pure_instructions
.globl _main
.align 4, 0x90
_main: ## @main
.cfi_startproc
## BB#0:
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
## InlineAsm Start
## InlineAsm End
movl $1, %eax
movl $4294967280, %ecx ## imm = 0xFFFFFFF0
.align 4, 0x90
LBB0_1: ## =>This Inner Loop Header: Depth=1
cmpl $0, (%rcx)
je LBB0_3
## BB#2: ## in Loop: Header=BB0_1 Depth=1
cmpl $100, %eax
leal 1(%rax), %eax
## kill: EAX<def> EAX<kill> RAX<def>
jl LBB0_1
LBB0_3: ## %.critedge
## InlineAsm Start
## InlineAsm End
xorl %eax, %eax
popq %rbp
retq
.cfi_endproc
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
