lkml.org 
[lkml]   [2005]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Volatile vs Non-Volatile Spin Locks on SMP.
    Date
    Joe Seigh wrote:
    > For synchronization you need memory barriers in most cases and the only
    > way to get these is using assembler since there are no C or gcc intrinsics
    > for these yet. For inline assembler, the convention seems to be to use
    > the volatile attribute, which I take as meaning no code movement across
    > the inline assembler code. It if doesn't mean that then a lot of stuff
    > is broken AFAICT.
    >

    Usenet rule #1. If you don't find something in the documentation, you
    will find it after you post about it. Volatile does seem to be documented
    somewhat in the gcc docs
    http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Extended-Asm.html#Extended-Asm

    I was using "memory" in the clobber list as the main thing to keep optimization from
    occurring across inline asm. This seems to say that you also need to say "volatile" to
    tell the compiler that you really mean it.

    "If your assembler instructions access memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GCC to not keep memory values cached in registers across the assembler instruction and not optimize stores or loads to that memory. You will also want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does not count as a side-effect of the asm. If you know how large the accessed memory is, you can add it as input or output but if this is not known, you should add `memory'."

    Also this needs to be looked at, i.e. does "sequence" mean in program order or with no interleaved
    C statements.

    "Similarly, you can't expect a sequence of volatile asm instructions to remain perfectly consecutive. If you want consecutive output, use a single asm. Also, GCC will perform some optimizations across a volatile asm instruction; GCC does not “forget everything” when it encounters a volatile asm instruction the way some other compilers do."

    One of the problems with volatile in C was that the compiler could move code around the volatile
    accesses and even accesses to other volatile variables. This was a problem that Java had and
    which they fixed with JSR-133 so you could actually do useful things with volatile in Java. It's
    just worse in C since C has nowhere as useful or clear definitions to work with. The only
    reason you can get away with something like

    do {
    while (lock != 0);
    } while (!testandset(&lock)); // interlocked test and set

    is the correctness of the code isn't affected by how the compiler treats
    the test for lock != 0 as long as it terminates in a finite amount of time. Or by the fact
    that's not the best way to do a spin wait on hyperthreaded Intel processors. Intel
    recommends you use a PAUSE intstruction in the wait loop.

    Anyway it looks like I'll have to do a little more augury on the gcc docs. :)


    --
    Joe Seigh

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-07-18 15:42    [W:0.025 / U:1.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site