RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
david.holmes at oracle.com
Wed Sep 11 22:58:16 UTC 2019
So if I read this right, the renaming will cause the C++11 thread_local
to be used always on Windows (due to our use of VS 2017) but for Solaris
Studio and gcc it will only be enabled if we explicitly ask for C++11
support - is that right?
I see Windows Visual Studio and Solaris Studio clearly state the
equivalence of the two mechanisms. I'm expecting gcc is the same, but I
don't see that clearly stated.
On 12/09/2019 8:23 am, Per Liden wrote:
> On 9/12/19 12:12 AM, Kim Barrett wrote:
>>> On Sep 11, 2019, at 5:37 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> Instead for VS we probably need to do an MSVC version check to decide
>>> whether to define thread_local to __declspec(thread), but I don't
>>> know which
>>> version of VS starts providing it natively. Either that or prune the
>>> set of
>>> (at least purportedly) supported versions somewhat.
>> According to boost.config and various other places I found, it appears
>> thread_local first shows up in Visual Studio 2015. So having a
>> __declspec(thread) definition protected with "#if _MSC_VER < 1900"
>> should do
>> the trick.
> I sort of came to the same conclusion. According to this table ,
> there's "Partial" support in VS2010, and full support in VS2015. No
> details on what "Partial" means. Some additional googling vaguely
> suggests that "Partial" refers to support for "__declspec(thread)" and
> full support would be "thread_local", but I can't find any official
> document saying that.
> Defining thread_local for pre-VS2015 (_MSC_VER < 1900) seems like a
> reasonable way forward.
> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.1
More information about the hotspot-dev