Is _Thread_local independent from __STDC_NO_THREADS__?

Question

It seems that currently _Thread_local is independent from __STDC_NO_THREADS__.

Consequence: even if an implementation defines __STDC_NO_THREADS__ to 1, then it still needs to support (at least to accept) _Thread_local. I guess that it is a defect. Is that correct?

---

UPD: Relevant proposal for C2x: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2291.htm.

Answer 1

That is correct but it's not necessarily a defect

_Thread_local is a storage duration added to the C programming language with the release of C11, and you're right, it is not explicitly associated with the threads.h library header file. It acts like a static variable that is only visible to one thread, so that each thread can have their own local static-like variables.

A conforming C11 compiler that defines __STDC_NO_THREADS__ to 1 need not include or support the functions or types in threads.h but must still support the duration specifier _Thread_local. This allows programmers writing multi-threaded programs in C using non-standard threading libraries such as the POSIX standard pthread.h to declare static-like variables local to a specific thread in their programs, even if threads.h is not supported in said compiler.

As you pointed out there's a proposal to add it to the list of things that need not be included when __STDC_NO_THREADS__ is defined as 1, but I imagine there will be debate on both sides as to its utility for older longer-established threading libraries, even when the C-standard threads.h library is not yet supported.

Answer 2

It seems that currently _Thread_local is independent from __STDC_NO_THREADS__.

Yes.

Consequence: even if an implementation defines STDC_NO_THREADS to 1, then it still needs to support (at least to accept) _Thread_local.

Yes.

I guess that it is a defect. Is that correct?

It is not a defect. There is nothing inconsistent there, and no particular problem for a C implementation that does not support multithreading to recognize and accept the _Thread_local storage class specifier. In such an implementation, there is no meaningful distinction between thread storage duration and static storage duration, because the single thread of each program has the same lifetime as the program itself. _Thread_local places very little extra burden on developers or purveyors of such implementations.

That there is a proposal to make support of the _Thread_local storage class specifier optional in C2X means very little, and I do hope that proposal is not accepted. We do not need more optional features in C than we already have, especially not optional keywords or syntactic constructs, and _Thread_local does no harm to implementations that don't support threads.