RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local

[David Holmes]

Hi Per,

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.

Thanks,
David

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 [1], 
> 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
> 
> /Per
> 
> [1] 
> https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?redirectedfrom=MSDN#c11-core-language-features-table-concurrency 
>