[boost] Re: Thread-Local Storage (TLS) and templates

From: Ken Hagan (K.Hagan_at_[hidden])
Date: 2003-02-24 05:35:20

Alexander Terekhov wrote:
>
> I, for one, believe strongly that "&k" is nothing but
>
>     "static_cast<typeof(k)*>(pthread_getspecific(__k_key));"
>
> It *isn't* a compile-time constant (just like &errno isn't a compile
> time constant).

MSVC has no pthread_getspecific(), so I venture to suggest that
your belief probably isn't valid for that compiler.

> Now, for some reason [that's beyond my understanding],
> you seem to want to make "&k" be treated as "(k*)&__k_key" if/when it
> is used as template argument... so that one can pretend that "&k" is
> a compile-time constant.

The reason isn't beyond your understanding, since you've just
stated it. It is syntactic sugar.

I could write...

    int fk() { return k; }

and re-cast my template to expect a pointer to function and then
write C<&fk>. This is perfectly legal under the current language
rules, and gives a type whose behaviour depends on the thread that
is using it.

I'd rather not. Writing the helper function is harmless enough,
but why should I have to maintain two templates, one for ints
and another for functions-returning-ints.

The original post asked what the existing practice was. For MSVC
at least, the existing practice is to allow the syntactic sugar.

> But it isn't.

But it can be. No-one has written the standard for this yet. We
have a choice. We can make "&k" to be a compile time constant and
the code that yields a pointer-to-int at run-time can be invoked
"under the hood" if we choose.

> Furthermore, while the __k_key
> itself CAN be thread-private... the value that it holds shall not be
> thread-private, I believe strongly.

That's another matter, though as I pointed out in my earlier post,
if the language requires TLS data to be public and the OS makes it
private, it is trivial for the compiler to use the private area to
store a pointer to somewhere public.