This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Ian Lance Taylor <iant at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, GNU C Library <libc-alpha at sourceware dot org>, Andrew Hunter <ahh at google dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Sun, 6 Oct 2013 01:38:00 -0400
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <523BD470 dot 6090203 at redhat dot com> <CAKOQZ8y85QBkd97cEEmP-4OgE2KizCqknrVR_n44pwBGMs5uAw at mail dot gmail dot com> <523C88D1 dot 6090304 at redhat dot com> <20130920175246 dot GE20515 at brightrain dot aerifal dot cx> <1380705404 dot 8757 dot 1847 dot camel at triegel dot csb> <20131002205046 dot GT20515 at brightrain dot aerifal dot cx> <1381010778 dot 8757 dot 3460 dot camel at triegel dot csb>
On Sun, Oct 06, 2013 at 12:06:18AM +0200, Torvald Riegel wrote:
> On Wed, 2013-10-02 at 16:50 -0400, Rich Felker wrote:
> > On Wed, Oct 02, 2013 at 11:16:44AM +0200, Torvald Riegel wrote:
> > > On Fri, 2013-09-20 at 13:52 -0400, Rich Felker wrote:
> > > > On Fri, Sep 20, 2013 at 01:41:37PM -0400, Carlos O'Donell wrote:
> > > > > Will our TLS variables become lock-free atomic objects?
> > > >
> > > > I don't see how this question is related at all. Atomic in the C11
> > > > sense has to do with synchronization between processors, not signals.
> > > > The memory model for access to objects from signal handlers should not
> > > > define the behavior when the signal handler accesses an object whose
> > > > modification the signal handler interrupted, except for objects of
> > > > type sig_atomic_t or character types (I added the latter because the
> > > > C11 memory model already requires byte-granularity write operations),
> > >
> > > You mean plain character types like a non-atomic char? I doubt that
> > > trying to give guarantees for those is right because it would prevent
> > > optimizations.
> >
> > The optimizations are already forbidden by C11 and POSIX memory
> > models. For example, if you have:
> >
> > char x[2];
> >
> > it's legal for threads A and B to access x[0] and x[1] concurrently
> > without any locking.
>
> Those are separate memory locations, and this holds independent of the
> type. Thus, I still don't see why you see similarities between a plain
> char and, say, sig_atomic_t.
The special property of sig_atomic_t is that it's modified atomically
with respect to signal handlers:
1. If the signal handler interrupts its modification, the signal
handler either sees the old value or the new value, not some other
value.
2. If the signal handler interrupts its modification, and modifies it
further, then after the signal handler returns, the program either
sees the value that was being written when the signal occurred, or
the value that was written by the signal handler, not some other
value.
My point is that char seems to automatically have this property on any
sane hardware, because, per the the POSIX and C11 memory models, you
can't access char objects as a read-modify-write sequence on a larger
unit of storage; you must perform single-byte accesses.
Rich