Re: Should glibc be fully reentrant? -- No. (Roland was right).

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2015-01-30 at 14:56 +0100, Florian Weimer wrote:
> On 12/15/2014 11:38 AM, Torvald Riegel wrote:
> > On Mon, 2014-12-15 at 09:52 +0100, Florian Weimer wrote:
> >> On 12/12/2014 05:17 PM, OndÅej BÃlka wrote:
> >>> On Fri, Dec 12, 2014 at 10:50:19AM +0100, Florian Weimer wrote:
> >>>> On 12/11/2014 03:11 PM, OndÅej BÃlka wrote:
> >>>>
> >>>>> Yes, I wrote that from head so I forgot volatile/asm barrier. One could
> >>>>> add requirement like needs to be compiled by gcc4-6+ instead pure C as
> >>>>> just using signals is not part of C standard.
> >>>>
> >>>> GCC emulates atomics with locks on some platforms, or some lock-free
> >>>> instruction sequences may not be reentrant.  This begins to look
> >>>> like a can of worms, unfortunately.
> >>>>
> >>> It uses only thread local variable. If they are not reentrant its
> >>> gigantic hole, you could not for example use sigaction as it could
> >>> set errno which is thread local variable.
> >>
> >> Sorry, what I'm trying to say is that atomics are not specified as 
> >> async-signal-safe
> > 
> > That's not correct in general.  My TLDR reply would be that all atomic
> > operations that claim to be lock-free are also async-signal-safe (see
> > GCC's __atomic_always_lock_free and the related C11/C++11 functions).  
> 
> That's not what C11 says.  I have reviewed this area of the standard
> several times, and I do believe it's unspecified in the sense that the
> standard intends to say something about it, but doesn't actually do so.

So let me give a more detailed answer :)  First, I agree that C11
doesn't say this specifically.

Nonetheless, if an atomic type claims that operations on it will always
be lock-free, then this means that they are also address-free (I know
that C++11 requires this, but don't have the citation handy; I'm not
100% sure whether C11 states the same, but the intent is for C11 to have
the same model as C++11).

If something is address-free and lock-free, the most likely
implementation is actually one backed by atomic HW instructions -- which
we can expect to be nonblocking/obstruction-free, in practice.  They
should also be reentrant, so overall async-signal-safe.  (I'm saying the
latter because while not specified in the standards, the current state
of discussion in ISO C++ SG1 (including the ISO C liaison person)
indicates that nobody sees an issue with allowing atomic operations in
signal handlers.)
The only other implementation I can think of right now is if you embed a
lock in the atomic type and make sufficient alignment requirements for
this type so that whenever it is mapped somewhere else, both the
internal lock and the actual value of the atomic type will be on the
same page.
Even though locks are blocking synchronization, the C11 implementation
would have to make the atomic type behave as if it would be lock-free.
That can either happen by relying on certain OS scheduler properties
(e.g., a round-robin scheduler and no crashes in the implementation of
the atomic type), or by making the particular lock integrated with the
scheduler (e.g., if on something like greenthreads, when blocked in lock
acquisition yield eventually so that other greenthreads run).
But if we expect signal handlers to run atomics and not violate their
lock-free properties, this implementation would have to guarantee the
same for the scheduling properties of signal handlers, which do suspend
the interrupted thread; thus, in the end, it would have to work in the
reentrant case too.
(Note that the latter case isn't well specified, because this overlaps
with the forward progress requirements the standard makes (which are
underspecified); but I'm working on this, see C++ N4156).