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.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
