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

[Torvald Riegel <triegel at redhat dot com>]

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:

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

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

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).

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.)


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.

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.

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.