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

[Mark Mitchell <mark at codesourcery dot com>]

--On Wednesday, May 22, 2002 02:17:55 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Wed, May 22, 2002 at 01:41:51PM -0700, Mark Mitchell wrote:
>> Is this really necessary?
>>
>> The traditional approach (i.e., make structures containing data
>> and then stuffing them into TLS) is workable, if slightly
>> cumbersome.
>
> This mechanism, or rather the run-time mechanism behind this,
> is significantly faster.  It also solves a number of problems
> with dynamic loading and wanting to share TLS data across DSO
> boundaries.

I see.

Well, heck, a new extension proposal gives me a chance to be an
annoying language lawyer. :-)

>> 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.
>
> This is intentionally vague.  Why would we mention pthread_create
> here when the run-time might actually use some other thread library?

Agreed; still if we're going to talk about threads we have to have some
model of what a thread is.  Even if we say "you create threads by some
implementation-defined means", we have to say that a thread is a flow
of control, that there are no guarantees about the values of
global variables that are not marked with __thread when accessed
simultaneously from multiple threads, etc.

In other words, by introducing __thread we've promoted threads to a
linguistic concept.  When it was just "pthread_create", well, that's
just some function with whatever behavior it needs to have, it's not
our problem from a language point of view.

Now, all of a sudden, it is.

>> Does the initialization take place in the parent or the
>> child?  (That matters if, say, longjmps occur in the midst of the
>> initializers.)
>
> There are no run-time initializers for TLS data.  They are
> specifically disallowed.

I missed that point.  That's great; it gets rid of one whole
set of issues.

(I assume that, in C++:

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

is OK.  In C++, this would not be a dynamic initialization, if there
were no __thread modifier, and it seems like you could do this in
the implementation you're envisioning as well.)

> Ooo good point.  I'd tend to want to force you to have it in the
> earliest declaration, but allow it to be dropped subsequently.

That seems best to me too.

We also need to note any GNU variable attributes don't work
with __thread variables.  I don't see any reason any of them shouldn't
work, except maybe "section", if there are any restrictions on what
sections get into the ELF segment in question.  (For example, if you
put a __thread variable in the ordinary .data section, is that going
to work?)  We can just say you get undefined behavior if you use the
section attribute with __thread without noting which sections might
happen to work.  Same might go for "shared" on Windows.

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