S
Steven T. Hatton
I pinned this to my desktop a while back so I'd remember to look at it:
http://people.redhat.com/drepper/tls.pdf
I just started reading it and realized that there may be a reason to extend the
language to support threading:
Increasing use of threads lead developers to wish for a better way of dealing with
thread-local data. The POSIX thread interface defines interfaces which allow storing
void * objects separate for each thread. But the interface is cumbersome to use. A key
for the object has to be allocated dynamically at run-time. If the key isn't used anymore
it must be freed. While this is already a lot of work and error prone it becomes a real
problem when combined with dynamically loaded code.
To counter these problems it was decided to extend the programming languages to
let the compiler take over the job. For C and C++ the new keyword thread can be
used in variable definitions and declarations. This is not an official extension of the
language but compiler writers are encouraged to implement them to support the new
ABI. Variables defined and declared this way would automatically be allocated local to
each thread:
__thread int i;
__thread struct state s;
extern __thread char *p;
The usefulness of this is not limited to user-programs. The run-time environment
can also take advantage of it (e.g., the global variable errno must be thread-local)
and compilers can perform optimizations which create non-automatic variables. Note
that adding thread to the definition of an automatic variable makes no sense and is
not allowed since automatic variables are always thread-local. Static function-scope
variables on the other hands are candidates, though.
Opinions?
http://people.redhat.com/drepper/tls.pdf
I just started reading it and realized that there may be a reason to extend the
language to support threading:
Increasing use of threads lead developers to wish for a better way of dealing with
thread-local data. The POSIX thread interface defines interfaces which allow storing
void * objects separate for each thread. But the interface is cumbersome to use. A key
for the object has to be allocated dynamically at run-time. If the key isn't used anymore
it must be freed. While this is already a lot of work and error prone it becomes a real
problem when combined with dynamically loaded code.
To counter these problems it was decided to extend the programming languages to
let the compiler take over the job. For C and C++ the new keyword thread can be
used in variable definitions and declarations. This is not an official extension of the
language but compiler writers are encouraged to implement them to support the new
ABI. Variables defined and declared this way would automatically be allocated local to
each thread:
__thread int i;
__thread struct state s;
extern __thread char *p;
The usefulness of this is not limited to user-programs. The run-time environment
can also take advantage of it (e.g., the global variable errno must be thread-local)
and compilers can perform optimizations which create non-automatic variables. Note
that adding thread to the definition of an automatic variable makes no sense and is
not allowed since automatic variables are always thread-local. Static function-scope
variables on the other hands are candidates, though.
Opinions?