------- Comment #10 from dwood at sybase dot com 2010-08-24 03:31 -------
(In reply to comment #9)
I don't disagree with the thread local writeup however it is lacking in
clarity. A "flow of control" must be associated with an execution context.
The existance of getcontext/setcontext allows both:
1) One flow of control to switch to another flow of control within a single
execution context;
2) and, a flow of control to move from one execution context to another.
In fact, __thread variables are not actual bound to a "flow of control" but to
a specific execution context, part of which is usually some kind of thread_t
structure associated with a kernel thread. If they where bound to a "logical
flow of control" then we wouldn't even need this discussion. Nowhere above did
I refer to user thread.
The above should be consistant with your comment that TLS is supported for OS
threads only. But the problem isn't the OS but the compiler.
"When the address-of operator is applied to a thread-local variable, it is
evaluated at run-time and returns the address of the current thread's
instance of that variable."
The question is which OS thread is the current OS thread when the address is
obtained to actually fetch the current thread local value. setcontext() avoids
changing %fs on Intel and %g7 on Sparc as it is really restoring a suspended
flow of control context onto a kernel thread's context as referenced by
%fs/%g7. Caching these across function calls in a MT program is faultly.
Just as users of compiler's shouldn't depend on implementation defined behavior
neither should compiler writers assume OS implementation defined behavior. OS
support for threads/setcontext existed prior to C's decision to provide basic
efficient access to TLS variables. If some OS implementations of setcontext
allow the context to be "pushed" onto a different kernel thread then it was
gotten from then caching the current kernel thread handle or TLS address across
function calls is wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
