On Thu, Oct 4, 2012 at 7:38 PM, Jason Merrill <ja...@redhat.com> wrote:
> Both C++11 and OpenMP specify that thread_local/threadprivate variables can
> have dynamic initialization and destruction semantics. This sequence of
> patches implements that.
>
> The first patch adds the C++11 thread_local keyword and implements the C++11
> parsing rules for thread_local, which differ somewhat from __thread. It
> also allows dynamic initialization of function-local thread_local variables.
>
> The second patch adds a __cxa_thread_atexit interface for registering
> cleanups to be run when a thread exits. The current implementation is not
> fully conformant; on exit, TLS destructors are supposed to run before any
> destructors for non-TLS variables, but I think that will require glibc
> support for __cxa_thread_atexit.
>
> The third patch implements dynamic initialization of non-function-local TLS
> variables using the init-on-first-use idiom: uses of such a variable are
> replaced with calls to a wrapper function, so that
>
> int f();
> thread_local int i = f();
>
> implies
>
> void i_init() {
> static bool initialized;
> if (!initialized)
> {
> initialized = true;
> i = f();
> }
> }
> inline int& i_wrapper() {
> i_init();
> return i;
> }
>
> Note that if we see
>
> extern thread_local int i;
>
> in a header, we don't know whether it has a dynamic initializer in its
> defining translation unit, so we need to make conservative assumptions. For
> a type that doesn't always get dynamic initialization, we make i_init a
> weakref and only call it if it exists. In the same translation unit as the
> definition, we optimize appropriately.
>
> The wrapper function is the function I'm talking about in
> http://gcc.gnu.org/ml/gcc/2012-10/msg00024.html
>
> Any comments before I check this in?
I wonder if an implementation is conforming that performs non-local TLS
variable inits at thread creation time instead (probably also would require
glibc support)?
Or if we have the extra indirection via a reference anyway, we could
have a pointer TLS variable (NULL initialized) that on the first access
will trap where in a trap handler we could then perform initialization
and setup of that pointer.
Should we document our choice of implementation somewhere in the
manual? And thus implicitely provide the hint that using non-local TLS
variables with dynamic initialization comes with an abstraction penalty
that we might not be easily able to remove?
Thanks,
Richard.
> Jason
