This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3 0/6] Add support for ISO C11 threads.h
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