[lkml]   [2006]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] spinlocks: remove 'volatile'

    On Sat, 8 Jul 2006, Albert Cahalan wrote:
    > >
    > > 1. The volatile implementation of gcc is correct. The standard does not
    > > talk about busses, not even about SMP.
    > The standard need not. An implementation must deal
    > with whatever odd hardware happens to be in use.

    Not really.

    The fact is, "volatile" simply doesn't inform the compiler enough about
    what the effect of an access could be under various different situations.

    So the compiler really has no choice. It has to balance the fact that the
    standard requires it to do _something_ different, with the fact that
    there's really not a lot of information that the user gave, apart from the
    one bit of "it's volatile".

    So the compiler really has no choice.

    Btw, I think that the whole standard definition of "volatile" is pretty
    weak and useless. The standard could be improved, and a way to improve the
    definition of volatile would actually be to say something like

    "volatile" implies that the access to that entity can alias with
    any other access.

    That's actually a lot simpler for a compiler writer (a C compiler already
    has to know about the notion of data aliasing), and gives a lot more
    useful (and strict) semantics to the whole concept.

    So to look at the previous example of

    extern int a;
    extern int volatile b;

    void testfn(void)

    _my_ definition of "volatile" is actually totally unambiguous, and not
    just simpler than the current standard, it is also stronger. It would make
    it clearly invalid to read the value of "b" until the value of "a" has
    been written, because (by my definition), "b" may actually alias the value
    of "a", so you clearly cannot read "b" until "a" has been updated.

    At the same time, there's no question that

    addl $1,a
    addl $1,b

    is a clearly valid instruction sequence by my simpler definition of
    volatile. The fact that "b" can alias with itself is a tautology, and is
    true of normal variables too, so any combination of ops on one variable
    (any variable always aliases _itself_) is by definition clearly always
    valid on a "volatile" variable too, and thus a compiler that can do the
    combination of "load + increment + store" on a normal variable should
    always do so on a volatile one too.

    In contrast, the current C standard definition of "volatile" is not only
    cumbersome and inconvenient, it's also badly defined when it comes to
    accesses to _other_ data, making it clearly less useful.

    I personally think that my simpler definition of volatile is actually a
    perfectly valid implementation of the current definition of volatile, and
    I suggested it to some gcc people as a better way to handle "volatile"
    inside gcc while still being standards-conforming (ie the "can alias
    anything" thing is not just clearer and simpler, it's strictly a subset of
    what the C standard allows, meaning that I think you can adopt my
    definition _without_ breaking any old programs or standards).

    But there really is no way to "fix" volatile. You will always invariably
    need other things too (inline assembly with "lock" prefixes etc) to
    actually create true lock primitives. The suggested "can alias anything"
    semantics just clarify what it means, and thus make it less ambiguous. It
    doesn't make it fundamentally more useful in general.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.023 / U:28.024 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site