C++ Logo


Advanced search

[wg14/wg21 liaison] N2654 and _Thread_local versus thread_local

From: Hubert Tong <hubert.reinterpretcast_at_[hidden]>
Date: Mon, 4 Oct 2021 15:33:27 -0400
The paper does not change the de jure status quo of this concern; however,
I will note that it probably changes the situation in practice:
_Thread_local is more like C++'s constinit thread_local than plain

I cannot recommend for users of C to adopt using thread_local for mixed
C/C++ uses because thread_local for C++ is more expensive than
_Thread_local is in C.
C++ uses of a thread_local variable from a translation unit that does not
define said variable must, for deferred-initialization implementations
(i.e., all implementations I am aware of), assume that the variable may
have dynamic initialization/finalization.

I should also point out that it is a reality of some existing
implementations that variables defined _Thread_local in C will fail to link
when uses in C++ are declared thread_local (without constinit). It is a
reality with more existing implementations that variables defined
thread_local in C++ with dynamic initialization/finalization could end up
uninitialized/unregistered when accessed via _Thread_local declarations in

This paper exacerbates the confusion between C's _Thread_local and C++'s

-- HT

Received on 2021-10-04 14:33:55