lkml.org 
[lkml]   [2007]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Is gcc thread-unsafe?


    On Fri, 26 Oct 2007, Bart Van Assche wrote:
    >
    > You can find my proposal to improve gcc here:
    > http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html

    Btw, I think this is fine per se, but putting "__attribute__((acquire))"
    on the functions that acquire a lock does seem to be problematic, in that
    quite often you might well want to inline those things. How would you
    handle that?

    The fact is, the whole optimization is broken. You should never do
    extraneous writes to anything but registers (or your own spill pool on the
    stack - anything that hasn't had its address taken and cannot be visible
    to outsiders). A C compiler should basically do what the user asks it to
    do, and that means that it simply should be _very_ nervous about doing
    optimizations that can have visible secondary effects.

    So the first question that should be asked is: "is that optimization even
    worth it in the first place outside of registers and the spill pool?"

    If an optimization introduces visible behaviour differences to the
    "obvious" stupid interpretation of the code, it should automatically be
    something that should be given a lot of thought, and perhaps not enabled
    at all by default (where "default" is certainly normal optimization
    levels).

    And different languages have different usages. In C, it's quite common
    (and _possible_) for the programmer to specify how to do things at a
    fairly low level. That's not true in all other languages, and it affects
    how a compiler should optimize things. In C, a compiler should give more
    weight to "this is how the user specified the solution" because in C,
    programmers really *do* that.

    So I don't think your proposal is wrong, but I think before even going to
    something like that, you should ask yourself: "was that a valid
    optimization to start with?"

    (That said, there may well be *other* reasons for wanting gcc to know
    about lock/unlock behaviour and teaching gcc about barriers. If gcc starts
    getting more threading knowledge, gcc may well need to have that kind of
    information in other places).

    Linus
    -
    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: 2007-10-26 17:29    [W:0.029 / U:60.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site