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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-02-21 07:06:28

Ken Hagan wrote:

[ ... &k ... ]

> So presumably we are all now in complete agreement, except perhaps

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). 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. But it isn't. Furthermore, while the __k_key 
itself CAN be thread-private... the value that it holds shall not be 
thread-private, I believe strongly. Here's some "random" refs/quotes:

A) http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html

"....
 Requirements

 It is important that it be possible to implement the thread-specific 
 data interface without the use of thread private memory. To do 
 otherwise would increase the weight of each thread, thereby limiting 
 the range of applications for which the threads interfaces provided 
 by IEEE Std 1003.1-2001 is appropriate.

 The values that one binds to the key via pthread_setspecific() may, 
 in fact, be pointers to shared storage locations available to all 
 threads. It is only the key/value bindings that are maintained on a 
 per-thread basis, and these can be kept in any portion of the 
 address space that is reserved for use by the calling thread (for 
 example, on the stack). Thus, no per-thread MMU state is required 
 to implement the interface. On the other hand, there is nothing in 
 the interface specification to preclude the use of a per-thread MMU 
 state if it is available (for example, the key values returned by 
 pthread_key_create() could be thread private memory addresses).

 Standardization Issues

 Thread-specific data is a requirement for a usable thread interface. 
 The binding described in this section provides a portable thread-
 specific data mechanism for languages that do not directly support 
 a thread-specific storage class. A binding to IEEE Std 1003.1-2001 
 for a language that does include such a storage class need not 
 provide this specific interface.

 If a language were to include the notion of thread-specific storage, 
 it would be desirable (but not required) to provide an implementation 
 of the pthreads thread-specific data interface based on the language 
 feature. For example, assume that a compiler for a C-like language 
 supports a private storage class that provides thread-specific 
 storage. Something similar to the following macros might be used to 
 effect a compatible implementation:

 #define pthread_key_t                   private void *
 #define pthread_key_create(key)         /* no-op */
 #define pthread_setspecific(key,value)  (key)=(value)
 #define pthread_getspecific(key)        (key)

 Note: For the sake of clarity, this example ignores destructor 
 functions. A correct implementation would have to support them."

-and-

B)

"There's really nothing special about ELF (or Tru64) TLS. It's just 
 TSD with a different key space (your dtv array index, or in our case 
 literally a separate TSD key space mapped into the same TCB vector). 
 __tls_get_addr is just pthread_getspecific() with the allocation and 
 initialization of a TSD value built in (because it can find the size 
 and an initialization template automatically). It's nice to have that 
 built in to the compiler and linker, but that's a convenience and 
 nothing radically different." -- Butenhof [http://tinyurl.com/3047]

regards,
alexander.