This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] Optimize generic spinlock code and use C11 like atomic macros.


* Torvald Riegel:

>> On 12/16/2016 09:12 PM, Florian Weimer wrote:
>> > That's undefined:
>> >
>> > “If an attempt is made to refer to an object defined with a
>> > volatile-qualified type through use of an lvalue with
>> > non-volatile-qualified type, the behavior is undefined.”
>> >
>> > But we cannot drop the volatile qualifier from the definition of
>> > pthread_spinlock_t because it would change the C++ mangling of
>> > pthread_spinlock_t * and similar types.
>
> Generally, I wouldn't agree with Florian's comment.  However, all we are
> interested in is the storage behind the volatile-qualified type.  Users
> aren't allowed the object through other means than the pthread_spin*
> functions, so if we cast everywhere, we'll never have any
> volatile-qualified accesses.

The spinlock is defined with the volatile qualifier.  This means that
accesses without the qualifier are undefined.

> I believe none of the architectures we
> support makes weaker requirements on alignment for volatile-qualified
> than for non-volatile-qualified types, so I can't see any problem in
> practice with the cast.

We also need separate compilation or some other optimization barrier.

If GCC can prove that code accesses a volatile object in this matter,
it can assume that the code never executes and eliminate it (and its
surrounding code).

We could talk to the GCC folks and ask for a suitable GCC extension.
Like you said, there shouldn't be any ABI concerns which would make
this difficult.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]