Can static combinable<T> be used as a placeholder to thread_local?
-
27-09-2019 - |
Question
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?
Solution
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.