Which functions act as memory barriers?

Discussion in 'C Programming' started by Jorge Peixoto, Nov 29, 2007.

  1. 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.
     
    Jorge Peixoto, Nov 29, 2007
    #1
    1. Advertising

  2. In article <>,
    Jorge Peixoto <> wrote:

    >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
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Nov 29, 2007
    #2
    1. Advertising

  3. Jorge Peixoto <> wrote:
    > 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.

    --
    pa at panix dot com
     
    Pierre Asselin, Nov 30, 2007
    #3
  4. "Jorge Peixoto" <> wrote in message
    news:...
    >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...
     
    Chris Thomasson, Nov 30, 2007
    #4
  5. Jorge Peixoto

    Kaz Kylheku Guest

    On Nov 29, 6:57 am, Jorge Peixoto <>
    wrote:
    > 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?
     
    Kaz Kylheku, Nov 30, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xiangliang Meng
    Replies:
    1
    Views:
    1,611
    Victor Bazarov
    Jun 21, 2004
  2. cppaddict
    Replies:
    1
    Views:
    375
    Siemel Naran
    Aug 5, 2004
  3. Dmitriy Vyukov

    Compiler ordering barriers in C++0x

    Dmitriy Vyukov, Apr 24, 2008, in forum: C++
    Replies:
    13
    Views:
    976
    Szabolcs Ferenczi
    May 5, 2008
  4. Steve
    Replies:
    0
    Views:
    117
    Steve
    Jun 4, 2010
  5. Antti J Ylikoski

    Re: functions which take functions

    Antti J Ylikoski, Apr 11, 2012, in forum: Python
    Replies:
    1
    Views:
    314
    Antti \Andy\ Ylikoski
    Apr 13, 2012
Loading...

Share This Page