Any thoughts on this issue?
>From: Steve Clamage <[EMAIL PROTECTED]>
>To: C++ core language mailing list
>Message c++std-core-9820
>
>Some compilers implement thread-local storage (TLS) for what would
>otherwise be global variables. The compiler and runtime system
>arrange for each thread to see its own copy of a global variable.
>
>Should the address of such a variable be allowed as a non-type
>template parameter? For example, this code is OK:
> extern int k;
> template< int* V > class C { ... };
> C<&k> ck;
>
>But what if k is designated thread-local? The actual variable
>referred to by the address of k will differ among threads.
>(I'm assuming an implementation where &k results in a link-time
>constant whether k is an ordinary or thread-local variable.)
>
>In favor of allowing k to be thread-local:
>Converting a multi-process program to multi-thread is simple.
>Just declare per-process variables to be thread local. Template and
>other usage of such variables remains separate per thread as it was
>per process.
>
>Against allowing k to be thread-local:
>What does the ODR mean in this situation? (Counter-counter
>argument: threaded programs and per-thread variables could
>mean that the ODR needs a different definition anyway.)
>
>If a programmer instantiates C on a thread variable, would
>having thread-specific behavior be expected or unexpected?
>
>What is existing practice among compilers that support TLS?
>
>---
>Steve Clamage, [EMAIL PROTECTED]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
