Boost logo

Boost :

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-02-18 14:35:18

Any thoughts on this issue?

>From: Steve Clamage <stephen.clamage_at_[hidden]>
>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, stephen.clamage_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at