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 10/26/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
    >
    > On Fri, 26 Oct 2007, Linus Torvalds wrote:
    > >
    > > 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?
    >
    > Thinking some more about this, you really have two cases:
    > - full functions taking/releasing locks (possibly conditionally, ie
    > with something like trylock and/or based on argument values).
    >
    > You simply *cannot* require these to be marked, because the locking may
    > have been done indirectly. Yes, you can mark things like
    > "pthread_mutex_trylock()" as being an acquire-function, but the fact
    > is, users will then wrap these things in *other* functions, and return
    > their return values.
    >
    > Ergo: a compiler *must* assume that a function call that it
    > didn't inline involves locking. There's no point in adding some
    > gcc-specific attributes to system header files, because it's not going
    > to fix anything in any portable program.

    You have a point here.

    > - inline assembly (together with, potentially, compiler primitives).
    > That's the only other way to reliably do locking from C.
    >
    > This one gcc could certainly extend on. But would there really be any
    > upside? It would be easier/better to say that inline assembly (at least
    > if it clobbers memory or is volatile) has the same serialization issues
    > as a function call.

    A problem is that the serialization properties defined for functions
    in the C standard only apply to volatile variables, not to
    non-volatile variables. But for asm statements this can be solved by
    adding memory to the list of clobbered registers -- this will prevent
    any reordering of manipulations of non-volatile variables and asm
    statements.

    Andrew, do you know whether gcc currently contains any optimization
    that interchanges the order of accesses to non-volatile variables and
    function calls ?

    > So the fact is, any compiler that turns
    >
    > if (conditional)
    > x++;
    >
    > into an unconditional write to x (where 'x' is potentially visible to the
    > outside - global visibility or has had its address taken) is just broken.
    >
    > No ifs, buts or maybes about it. You simply cannot do that optimization,
    > because there is no way for the compiler to know whether the conditional
    > implies that you hold a lock or not.

    I agree with the above, but I see this as a different issue -- it
    wasn't my intention to solve this with my proposal for acquire and
    release attributes.

    Bart Van Assche.
    -
    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 19:09    [W:0.026 / U:123.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site