[PATCH v3 0/6] Add support for ISO C11 threads.h

[Martin Sebor]

On 03/27/2017 03:25 AM, Torvald Riegel wrote:
> On Tue, 2017-03-21 at 16:49 +0000, Joseph Myers wrote:
>> On Tue, 21 Mar 2017, Adhemerval Zanella wrote:
>>
>>>> Did you review those C11 DRs related to threads to make sure the
>>>> implementation behaves properly regarding issues raised in those DRs (and
>>>> that there are tests of this if applicable)?
>>>>
>>>> Current DR log: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2109.htm
>>>>
>>>
>>> Thanks for the link, I will check this out. Do you know off the top of your
>>> head which ones would be applicable?
>>
>> It appears to be: 405 414 416 424 449 469 470 479 480 493.
>>
>
> Here's my take on these:

I've reviewed the DRs and your comments below.  I agree with
your view and just for clarity provide some additional comments
of my own.

>
> 405, 414:
> Some of these DRs affect implementations, but there's nothing
> contentious in these I believe.

Agreed.

>
> 416, 424, 449:
> I haven't looked at these before and can't comment on them currently.

The 416 corrignedum was accepted.  424 was rolled into 416, and
449 resulted in no changes.

>
> 469:
> What I proposed should be clarified by C matches our implementation.
> The committee seems to agree.
> POSIX makes stronger requirements on the implementation, which we do not
> implement (and what I do not intend to implement).  I have arguend in a
> POSIX bug that POSIX should not make these stronger requirements (sorry,
> don't have the bug number handy).

This issue was closed with the expectation that it will be resolved
in C2X.  Unless someone else steps up it will likely mean that you
(or we) will have to propose the changes you/we would like to see.

> 470:
> C11's requirements on implementations are weaker than what POSIX
> requires. Arguably, POSIX should require what C11 requires.
> We need to check the lowlevellock implementation, in particular on archs
> that use LL/SC (I'm not aware of an arch with a true CAS instruction
> that can fail spuriously).
> Our generic lowlevellock implementation on master still uses the
> old-style atomics (ie, atomic_compare_and_exchange_bool_acq); if we move
> to C11 atomics, C11 (with DR 470's proposed corrigendum applied) would
> require our atomic_compare_exchange_weak_acquire, whereas current POSIX
> would require the strong variant of the CAS.
> Thus, what we do is okay in terms of C11.
> I don't recall right now whether we have an open Austin Group bug about
> POSIX allowing a spurious failure; I believe we have, or we should,
> because this is also related to what memory order is required for lock
> acquisitions (generally, not just trylock).
> (Stefan, that's why I'm CC'ing you too, this is relevant for
> pthread_spin_trylock too, but I can't remember right now whether we
> already discussed this or not.)
>

The resolution for the DR was accepted and the DR is closed.
The change will be in the 2017 C11 TC.  If other changes are
required here a new issue will need to be submitted that will
be considered for C2X.

>
> 479:
> Our implementation is correct.
> What C++ requires from a program, and what the committee agrees C11
> should require, is stronger than what POSIX requires.  This means that
> the C11 implementation of trylock would not have to conservatively abort
> transactions in the lock elision implementation for the non-recursive
> mutexes.

Here it sounds like as the authors of the DR we're on the hook
for providing wording that the rest of WG14 agrees with.  This
too will be considered for C2X.

>
> 480:
> A specification bug.  Committee agrees with what we implement.
>
>
> 493:
> The intent of the standard as stated by the committee in this DR seems
> to be compatible with what glibc implements and could implement in the
> foreseeable future.

This DR is still Open and needs a proposed resolution.

>
> Martin,
> please correct anything I got wrong.  Also, I assume you are tracking
> these DRs, so please give us a heads up if the committee should change
> its mind in a way that conflicts with what we implement.

Most of the DRs on the list are in a Closed state with (presumably)
clear resolutions.  As I understand the C11 schedule, the outstanding
ones that are still Open or labeled Future will not be fixed in
the final corrigendum that's expected to be finalized this year.
After 2017 there will not be any further C11 corrigenda.  C2X will
the next work item on WG14's list.

There's been a lot of talk over the last few WG14 meetings about
the whole threads section needing an overhaul.  I don't know if
anyone is actually working on it but if it were to happen (for
C2X) there is some risk that an implementation coded to the C11
spec not conforming to the cleaned up and improved C2X spec.

Martin

PS Besides the issues list there are at least two other documents
that could offer additional insight or guidance here.  The C2X
charter that outlines the guiding principles for C2X development:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm

In addition, the WG14 Convener maintains a standing document where
he tracks a subset of issues that have come up over the years and
that he wants WG14 to review for C2X.  This is not a complete list,
just some select items.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2087.htm