Re: why the barrier() can not take effect?

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

 



On 12/24/2010 12:02 PM, Parmenides wrote:
I don't know why you'd expect a difference, really.  Try this:

I just want to know precisely what measures the gcc take when a asm
statement including a clobber of "memory", rather merely than a
general description in the gcc manual. In Linux kernel code, the
barrier() appears frequently in some kernel funcitons. So, I wish to
get the exactly meaning of the barrier().

int s = 0;

So, just the variables which might be modified by some outer code
unpredictable, such as interrupt handlers, other processes, etc, will
be given more cares by the gcc. But, we need not to worry about
whether or not a local variable in some function is consistent with
the corresponding register, because it is impossible that a local
variable will be modified outside the current code. Is that true?

This is defined by the C standard itself. The compiler *knows* that a local variable can only be modified by the code in the scope where it is defined, unless that code passes the address of the variable to code outside that scope. If the code does pass the address of the variable elsewhere, the variable won't be located in a register. Thus, variables that are candidates to be located in registers are also guaranteed to not be affected by memory barriers and other such operations on memory.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@xxxxxxxxxx
Check us out at www.digium.com & www.asterisk.org


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux