This is the mail archive of the
mailing list for the glibc project.
Re: Should glibc be fully reentrant? -- No. (Roland was right).
- From: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 15 Dec 2014 11:38:15 +0100
- Subject: Re: Should glibc be fully reentrant? -- No. (Roland was right).
- Authentication-results: sourceware.org; auth=none
- References: <5488F9C6 dot 9080605 at redhat dot com> <54898FE0 dot 8060701 at redhat dot com> <20141211133353 dot GB10717 at domone> <5489A11A dot 3080300 at redhat dot com> <20141211141136 dot GA17090 at domone> <548ABA5B dot 9090002 at redhat dot com> <20141212161750 dot GA22945 at domone> <548EA164 dot 5040004 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
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
* 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
* 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.