|
|
Threads-Devel : |
Subject: Re: [Threads-devel] BOOST_THREAD_LOCAL support (was: hierarchical_mutex for lock hierarchies)
From: Fredrik Orderud (forderud_at_[hidden])
Date: 2013-02-21 08:52:47
On Mon, Feb 18, 2013 at 9:05 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:
> From the wikipedia link it seems that a lot of compilers 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.
>
> Some important limitations: From gcc manual
> "Thread-Local Storage
>
> 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*."
>
I've also read that, but have been unable to determine a concrete list over
which platforms are supported/unsupported. Do you know anything about this
yourself?
> "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<http://msdn.microsoft.com/en-us/library/cc429241.aspx>,
> 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<http://msdn.microsoft.com/en-us/library/cc429388.aspx>,
> in your DLL to allocate TLS if the DLL might be loaded with *LoadLibrary*
> ."
>
Yes Windows XP might pose a problem for programmatic library loading. Do
you know if upcoming boost releases are still required to support Windows
XP? Otherwise, we could possibly avoid the problem by stating that Windows
XP is not supported for this feature?
Also, the Boost 1.53 release notes includes a list of "primary test
compilers" (with platforms) and "additional test compilers". Does these
lists constitute the officially supported compilers and platforms, or is
Boost code also required to function on additional compilers/platforms?
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.
>
> Let me know if you need help in preparing a patch for Boost.Config.
>
I agree that BOOST_THREAD_LOCAL_RESTRICTED sounds like a realistic level of
ambition. I'll definitely appreciate some help in preparing a patch. :-)
Regards,
Fredrik