|
|
Threads-Devel : |
Subject: Re: [Threads-devel] BOOST_THREAD_LOCAL support
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-02-21 13:49:07
Le 21/02/13 14:52, Fredrik Orderud a écrit :
> On Mon, Feb 18, 2013 at 9:05 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden] <mailto:vicente.botet_at_[hidden]>> wrote:
>
> |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*."
>
> 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?
Unfortunately no.
>
> "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?
Yes, I believe Windows XP will be supported yet. BTW, I use windows XP
to test the windows part.
>
> 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?
In theory each library author is free to support or not some
compilers/platforms, but in reality he should support the more common
platforms/compilers.
>
>> |||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. :-)
>
>
I will have some free time next week. Maybe you could post on the
development ML to request interest for the Boost.Config library.
Best,
Vicente