C++ thread_local with different threading library than std::thread

Question

C++11 has keyword thread_local. I wanted to know whether this keyword works as expected only with threads created using standard library (std::thread) or it is guaranteed to work with other threading libraries e.g. Windows CreateThread function or Unix pthread.

Microsoft documentation for visual studio states that:

The thread extended storage-class modifier is used to declare a thread local variable. For the portable equivalent in C++11 and later, use the thread_local storage class specifier for portable code. On Windows thread_local is implemented with __declspec(thread).

So thread_local works as expected in MS Visual Studio. I still wonder if the situation is true for other compilers and platforms.

Answer 1

The C++ standard defines a thread as follows at [intro.multithread]/1:

A thread of execution (also known as a thread) is a single flow of control within a program, including the initial invocation of a specific top-level function, and recursively including every function invocation subsequently executed by the thread. [ Note: When one thread creates another, the initial call to the top-level function of the new thread is executed by the new thread, not by the creating thread.  — end note ] Every thread in a program can potentially access every object and function in a program. Under a hosted implementation, a C++ program can have more than one thread running concurrently. The execution of each thread proceeds as defined by the remainder of this International Standard. The execution of the entire program consists of an execution of all of its threads. [ Note: Usually the execution can be viewed as an interleaving of all its threads. However, some kinds of atomic operations, for example, allow executions inconsistent with a simple interleaving, as described below.  — end note ] Under a freestanding implementation, it is implementation-defined whether a program can have more than one thread of execution.

Note how the above is not at all limited to threads created by std::thread. Moreover, the standard even acknowledges the existence of at least one thread of execution that is not necessarily created by std::thread, over at [intro.progress]/8:

It is implementation-defined whether the implementation-created thread of execution that executes main and the threads of execution created by std​::​thread provide concurrent forward progress guarantees. [ Note: General-purpose implementations are encouraged to provide these guarantees.  — end note ]

Furthermore, while the following is a note, and cannot be considered normative, it's still encouraging to read [thread.threads]/1:

[thread.threads] describes components that can be used to create and manage threads. [ Note: These threads are intended to map one-to-one with operating system threads.  — end note ]

Which to me all indicates that any thread_local storage can be used in any "thread of execution" that conforms to the above definition, regardless of whether it's created by std::thread or some implementation defined manner. I wouldn't expect a sane hosted implementation to behave otherwise.