views:

29

answers:

1

C++0x adds a new storage specifier thread_local which is not yet implemented in VS10.

However the Parallel Programming Library defines a Concurrency::combinable class which has a local() function which Returns a reference to the thread-private sub-computation.

Are there semantics for thread_local that can't be (easily) covered by having a static variable of type combinable<T>?

If not why was thread_local added to the core language if it can be implemented in a library?

+1  A: 

Why C++ added class objects whether it could be implemented by a library like something that GObject does in C? Because C++ wants class objects to be known at compile-time, this is more efficient. Therefore C++ class initialization/uninitialization is exception-safe (RAII).

Some features are more major and needed more implementation to be made. thread_local is a storage class specifier, so it can be known at compile-time and compiler can do much more optimization.

Also in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm have said:

Thread Variable Dynamic Initialization

At present, all implementations of thread-local storage do not support dynamic initalization (and presumably non-trivial destructors). There was mild consensus at the Mont Treblant meeting to support dynamic initialization of function-local, thread-local variables. The intialization of such variables is already guarded and synchronous, so new technology is not required. On the other hand, the implementation for dynamic initialization of namespace-scope variables is much more difficult, and may require additional linker and operating system support.

Why thread_local have been introduced as a new language keyword? It seems that the reason could be Thread Variable Dynamic Initialization.

PC2st