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 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.

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