Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Rich Felker]

On Sun, Oct 06, 2013 at 11:56:00PM +0200, Torvald Riegel wrote:
> On Sun, 2013-10-06 at 17:40 -0400, Rich Felker wrote:
> > 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.
> 
> It would prevent some of them -- but then we're talking not about plain
> char-typed variables anymore.  Also, volatiles and atomics aren't the
> same thing; 

I'm quite aware. None of this discussion has been about atomics in the
C11 or C++11 sense. The word "atomic" here has nothing to do with
synchronization between cores. In sig_atomic_t, it's just a part of
the name; in other usages, it's described the property whereby partial
changes to the object are never observed (described more precisely
earlier in this thread).

> > > 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
> > so.
> 
> That's the point: The compiler must not necessarily use single-byte
> accesses, as you seemed to say (see above).

The physical mechanism is irrelevant. If something is not observably
different from a single-byte write, then, for purposes of this
discussion, it's a single-byte write. The point, in any case, is that
the observable behavior must be as if single-byte writes exist and are
used for writing char-type objects. Of course, in some cases (e.g. if
multiple chars at adjacent addresses are written) then the compiler
can combine them without any observable effect.

Rich