This is the mail archive of the
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 17:40:57 -0400
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <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> <1381095401 dot 8757 dot 3814 dot camel at triegel dot csb>
On Sun, Oct 06, 2013 at 11:36:41PM +0200, Torvald Riegel wrote:
> > 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.
Adding volatile (which, BTW, also needs to be added to sig_atomic_t)
would avoid these ordering issues.
> 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.
Is that observably different from a single-byte write? I don't think