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
-
