Proposed resolution:

Change [compliance]/3:

3 The supplied version of the header <cstdlib> shall declare at least the functions abort(), atexit(), and exit() (18.5). The supplied version of the header <thread> either shall meet the same requirements as for a hosted implementation or including it shall have no effect. The other headers listed in this table shall meet the same requirements as for a hosted implementation.

Add the following line to table 15:

Table 15 — C++ headers for freestanding implementations

Subclause	Header(s)
...
[thread.threads] Threads	<thread>

Add to the <thread> synopsis in [thread.threads]/1 the line:

namespace std {

#define __STDCPP_THREADS __cplusplus

  class thread;
  ...

[ 2010 Pittsburgh: Ganesh's wording adopted and moved to Ready for Pittsburgh. ]

[ 2010-03-08 Pete adds: ]

Most macros we have begin and end with with double underbars, this one only begins with double underbars.

[ 2010 Pittsburgh: Adopt Ganesh's wording and move to Review. ]

[ 2010-02-26 Ganesh updates wording. ]

[ 2010-02-25 Pete moved to Open: ]

The proposed resolution adds a feature-test macro named __STDCPP_THREADS, described after the following new text:

The standard library defines the following macros; no explicit prior inclusion of any header file is necessary.

The correct term here is "header", not "header file". But that's minor. The real problem is that library entities are always defined in headers. If __STDCPP_THREADS is defined without including any header it's part of the language and belongs with the other predefined macros in the Preprocessor clause.

Oddly enough, the comments from Batavia say "We prefer that the macro be conditionally defined as part of the <thread> header." There's no mention of a decision to change this.

[ 2009-10 Santa Cruz: ]

Move to Ready.

[ Batavia (2009-05): ]

We agree with the issue, and believe it is properly a library issue.

We prefer that the macro be conditionally defined as part of the <thread> header.

Move to Review.

Addresses DE 18

Freestanding implementations do not (necessarily) have support for multiple threads (see [intro.multithread]). Applications and libraries may want to optimize for the absence of threads. I therefore propose a preprocessor macro to indicate whether multiple threads can occur.

There is ample prior implementation experience for this feature with various spellings of the macro name. For example, gcc implicitly defines _REENTRANT if multi-threading support is selected on the compiler command-line.

While this is submitted as a library issue, it may be more appropriate to add the macro in 16.8 cpp.predefined in the core language.

See also N2693.