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: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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, 06 Oct 2013 23:36:41 +0200
- 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> <20131006053800 dot GQ20515 at brightrain dot aerifal dot cx>
On Sun, 2013-10-06 at 01:38 -0400, Rich Felker wrote:
> 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.
The compiler could still do "arbitrary" stuff to non-atomic and
non-volatile char variables (reordering accesses, ...), provided that
when assuming a sequential program, the program would behave as if the
abstract machine would execute it. The atomics tell the compiler to not
assume that this is sequential code; therefore, a char-typed variable
doesn't have the stronger properties automatically.
On the C11 and C++11 models, I think a compiler could also use
multi-byte accesses with atomic read-modify-write ops as long as it
makes sure that those don't overlap with volatiles or similar.