On Mon, Feb 18, 2013 at 1:18 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I have added some comments in https://svn.boost.org/trac/boost/ticket/8094#comment:1.
Could you please explain what you meant with your comment regarding BOOST_THREAD_LOCAL for non-C++11 compilers Vicente?
As far as I can see, more or less "all" compilers (of relevance to boost) have supported either__declspec(thread) or
__thread for quite some years [1]. I therefore supect that BOOST_THREAD_LOCAL can be implemented with a small preprocessor block that only has to switch between thread_local,
__declspec(thread)
or
__thread "backends" (the
_MSC_VER check in my patch should probably be replaced with _WIN32 to also support Intel on windows). Please correct me if this view is naive.
From the wikipedia link it seems that a lot of compiler
s
support the feature, so it seems an interesting proposal for
Boost.Config. It would be interesting if the implementation takes
in account the version from which the feature is provided for each
compiler/platform.Thread-local storage (TLS) is a mechanism by which
variables
are allocated such that there is one instance of the variable per
extant
thread. The run-time model GCC uses to implement this originates
in the IA-64 processor-specific ABI, but has since been migrated
to other processors as well. It requires significant support from
the linker (ld
), dynamic linker (ld.so
),
and
system libraries (libc.so
and libpthread.so
),
so it
is not available everywhere."
"On Windows operating systems before Windows Vista, __declspec( thread ) has some
limitations. If a DLL declares any data or object as __declspec( thread ), it can cause
a protection fault if dynamically loaded. After the DLL is loaded
with LoadLibrary,
it causes system failure whenever the code references the __declspec( thread ) data. Because
the global variable space for a thread is allocated at run time,
the size of this space is based on a calculation of the
requirements of the application plus the requirements of all the
DLLs that are statically linked. When you use LoadLibrary,
you cannot extend this space to allow for the thread local
variables declared with __declspec(
thread ). Use the TLS APIs, such as TlsAlloc,
in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary."
There are for sure limitations regarding thread-local variables, such as MSVC not allowing dynamic initialization [2,3], but these limitations can be documented. Furthermore, we can recommend client code to only use the functionality subset supported by most/all compilers.
Yes, the best would be to document the more restricted use
that is portable on all the compilers.
It would be better
to name the macro BOOST_THREAD_LOCAL_RESTRICTED and let
BOOST_THREAD_LOCAL for compilers providing full thread_local.