Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk