On 10/26/07, Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
