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

[Torvald Riegel <triegel at redhat dot com>]

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

But the full situation is a little bit more complex.  C++11 specifies
that a lock-free operation should be lock-free indeed (ie, at least one
of the threads doing lock-free operations on the same memory object will
make progress eventually).

IIRC, it's currently not specified that signal handlers can use
lock-free atomic operations, but that is what the C++ committee
currently wants to achieve (because this does make sense, intuitively).
That's important because, when ignoring signals, assumptions about the
(eventual) fairness of your scheduler and the absence of crashes can
make a lock-based implementation of atomics lock-free.  This is not the
case anymore if you have a simple lock-based implementation and have
atomics in signal handlers, because a signal handler and the application
thread it suspended are not scheduled in a fair way; the thread will
block on the signal handler to finish before it can resume.

> and some actually aren't in practice.

I think that in glibc, as a rule of thumb, the atomic operations we
provide internally (ie, atomic_*) should be lock-free.  I think that's
already the case for most of the archs, with the following
exceptions/comments:
* All LL/SC style atomics are rather obstruction-free than lock-free,
unless we get stronger guarantees from hardware than the guarantees I've
heard about on powerpc, for example.
* I assume the archs that use kernel help for atomic ops to be lock-free
as well.
* IIRC, code for old SPARCs uses a set of builtin locks and TAS to
implement atomics.  This isn't lock-free.

Using this rule of thumb would allow us to assume atomics to be
async-signal-safe in glibc.

Outside of glibc, I agree that some atomics (notably those not claiming
to be lock-free) to be actually not async-signal safe.