Re: Is gcc thread-unsafe?

Linus Torvalds
2007-10-26T16:29:43Z

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 lik etrylock 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.

- 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.

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.

Linus