This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]