Re: Is gcc thread-unsafe?

["Bart Van Assche" <bart.vanassche@gmail.com>]

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/