Re: [Threads-devel] BOOST_THREAD_LOCAL support (was: hierarchical_mutex for lock hierarchies)

Subject: Re: [Threads-devel] BOOST_THREAD_LOCAL support (was: hierarchical_mutex for lock hierarchies)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-02-18 15:05:14

Le 18/02/13 20:16, Fredrik Orderud a écrit :
> On Mon, Feb 18, 2013 at 1:18 PM, Vicente J. Botet Escriba 
> <vicente.botet_at_[hidden] <mailto:vicente.botet_at_[hidden]>> 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.

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*."

"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*."

> ||
> |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.

Best,
Vicente