Re: Design hole in nptl (and more general in POSIX threads)

Roland McGrath <[email protected]> writes:
> Lazy allocation of TLS blocks is indeed not async-signal-safe.  Use
> of the static TLS block is async-signal-safe.  Use of the DTV is not truly
> async-signal-safe because it can be realloc'd by an unrelated lazy
> allocation in a signal handler.  But if you know that no signal handler
> induces such an allocation (which none should, since it's not
> async-signal-safe usage), then your non-handler code can safely use any
> kind of TLS.  So, if your TLS-using code uses the static or initial-exec
> TLS access model rather than one of the dynamic access models, you are fine
> because at startup time you will have both allocated the space and resolved
> your GOT entries (or static relocs) directly to thread-pointer offsets
> (i.e. such accesses do not use the DTV).  Moreover, if you have used the
> __thread variable in question in that thread already then you can always be
> sure that its DTV slot for your module is allocated and safe to use as long
> as no signal handler might do a lazy TLS allocation (which might realloc
> the DTV).

The __thread variable is static to a compilation unit which will be
included in a shared library, so I think the local dynamic model is
the best the compiler can use.  The static and initial-exec models are
out of reach.

My __thread structure contains the links of the list of threads to
send signals to.  Both adding threads to the list and traversing the
list sending signals require code to hold the same mutex.  So I have
always referenced my thread structure before using it in the signal
handler.  And I don't make any first references to TLS in my signal
handlers.  So it sounds like I'm okay.

While I appreciate your explanation, the paragraph above is not the
sort of language one would want to put in a spec.  When POSIX gets
around to recognizing the existence of __thread variables, it will
need to find a description of what is permissible that reveals less
about the implementation.  I hope they will not simply declare it
non-async-safe altogether.

Perhaps they could say that volatile __thread variables may be safely
referenced in signal-handling code only if they are first referenced
in non-signal-handling code.  (Without the 'volatile' qualifier, this
requirement would create a new class of variables for the compiler
which it could not optimize out references to.)