Which functions act as memory barriers?

[Jorge Peixoto]

I have just read in http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
that code like
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

doesn't need shared_data to be declared volatile, because the
spin_lock call causes the compiler to reload shared_data from memory.
Within the critical section, the compiler can optimize and load shared
data onto registers. Therefore, declaring shared_data as volatile
serves only to slow things down (assuming that any code that writes to
shared_data locks the_lock beforehand).

So, which functions have this "memory barrier" behavior of spin_lock?
I cannot find this on the internet. In particular, in this code

while (not_ready)
sched_yield();

does not_ready have to be declared as volatile (in my particular
system the code works perfectly without not_ready being volatile, but
I want to know if this is guaranteed) ?

Also, I find it amazing that this code is much faster than using
pthread_cond_signal.

And where can I read about this memory barrier concept? When searching
on the internet, I only found mentions of assembly-level memory
barriers, that is, memory barriers that avoid the CPU from reordering
memory operations across the memory barrier. I did not found anything
about this C-level memory barrier concept.

PS: I have mentioned some POSIX terms in my question, but I believe my
question can be answered with only Standard C knowledge, so I don't
think I am offtopic.

 

[Richard Tobin]

I have just read in
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
that code like
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

doesn't need shared_data to be declared volatile, because the
spin_lock call causes the compiler to reload shared_data from memory.
Within the critical section, the compiler can optimize and load shared
data onto registers. Therefore, declaring shared_data as volatile
serves only to slow things down (assuming that any code that writes to
shared_data locks the_lock beforehand).

So, which functions have this "memory barrier" behavior of spin_lock?
I cannot find this on the internet. In particular, in this code

while (not_ready)
sched_yield();

does not_ready have to be declared as volatile (in my particular
system the code works perfectly without not_ready being volatile, but
I want to know if this is guaranteed) ?

Also, I find it amazing that this code is much faster than using
pthread_cond_signal.

And where can I read about this memory barrier concept? When searching
on the internet, I only found mentions of assembly-level memory
barriers, that is, memory barriers that avoid the CPU from reordering
memory operations across the memory barrier. I did not found anything
about this C-level memory barrier concept.

If the compiler can't tell whether shared_data could be modified by
spin_lock(), either because it's a non-local variable or because its
address has been taken, then the compiler cannot assume that it's
unchanged, and will have to load it again.

On the other hand, if the compiler can see that the code of
spin_lock() doesn't change the memory, then it can assume it is
unchanged. It doesn't have to reload it just because there's a
function call. In this case you will need to declare it volatile.

-- Richard

 

[Pierre Asselin]

I have just read in http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
[ ... ]
So, which functions have this "memory barrier" behavior of spin_lock?
I cannot find this on the internet.

See the nearby file
http://kernel.org/doc/Documentation/memory-barriers.txt

As near as I can tell the barriers themselves are implemented in
assembly, separately for each architecture. It looks like the
files you want are the asm-xxx/system.h and sometimes the corresponding
alternative.h .

So in the end, it's not a C question... You can't do memory
barriers portably in C.

 

[Chris Thomasson]

I have just read in
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
that code like
spin_lock(&the_lock);
do_something_on(&shared_data);
do_something_else_with(&shared_data);
spin_unlock(&the_lock);

doesn't need shared_data to be declared volatile, because the
spin_lock call causes the compiler to reload shared_data from memory.
Within the critical section, the compiler can optimize and load shared
data onto registers. Therefore, declaring shared_data as volatile
serves only to slow things down (assuming that any code that writes to
shared_data locks the_lock beforehand).

So, which functions have this "memory barrier" behavior of spin_lock?
I cannot find this on the internet. In particular, in this code

while (not_ready)
sched_yield();

does not_ready have to be declared as volatile (in my particular
system the code works perfectly without not_ready being volatile,

Link-time optimizations aside for a moment, the compiler kind of has to be
somewhat pessimistic wrt the actions that sched_yield() takes:

http://groups.google.com/group/comp.lang.c++/msg/825828b63cf345fb

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/f4688431bed52b31

http://appcore.home.comcast.net/vzdoc/atomic/static-init
(section 2-2.2)

but I want to know if this is guaranteed) ?

Link-time optimizations can potentially break this, and the loop will spin
forever...

 

[Kaz Kylheku]

So, which functions have this "memory barrier" behavior of spin_lock?

For me, fread and fwrite are real memory barriers. I can't remember
for the life of me which of those middle two parameters is the number
of elements and which is the size. Also, is the FILE * stream pointer
first, and the void * buffer pointer last, or vice versa?