Re: thread-local storage: c front end and generic backend patch

[Mark Mitchell <mark at codesourcery dot com>]

--On Tuesday, May 21, 2002 06:09:01 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> The following adds support in the C front end for a new
> storage specifier keyword "__thread" that marks a variable
> to be allocated in storage private to every extant thread.

Is this really necessary?

The traditional approach (i.e., make structures containing data
and then stuffing them into TLS) is workable, if slightly
cumbersome.

It's great to have the proposed standardese.  That's very helpful.

There's no definition of "thread" in the standard, so saying that
these variables have the lifetime of "the thread" is probably
insufficient.  "Prior to thread startup" is also a bit unclear; we
don't know how to start a thread or what it means for it to be
started.  Does the initialization take place in the parent or the
child?  (That matters if, say, longjmps occur in the midst of the
initializers.)

You probably also need to say something about interactions between
__thread variables and initialization order.  For example:

  __thread int i = j;
  __thread int j = 7;

Does "i" get 0, or 7, or is this undefined behavior?

Similarly:

  extern __thread int i;

  int f() { return i + 2; }

  __thread int i = f();


Is:

  extern __thread int i;

  extern int i;

  int i;

legal?  (Can you drop the "__thread" after you've said it once?  What
if you don't say it the first time?)

In C++, what happens if an exception is thrown during construction of
a __thread variable?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com