简体   繁体   中英

What does C++11 consider to be a “thread”?

C++11 has some notion of threads. For example, it defines a new storage specifier thread_local , and specifies that for variables with this storage specifier, "there is a distinct object or reference per thread" [basic.stc.thread].

What is considered to be a "thread" for this purpose? Is it only threads created using the standard thread library (ie those represented by std::thread objects)? What about threads created by other means (for example, by using pthreads directly on Linux)? What if I use a library that provides user-space threads - does each of those get its own copies of thread_local objects (I don't really see how that could be implemented)?

If the answer is "it's implementation-defined what is considered to be a thread for purposes such as thread_local ", could someone give an example of how one well-known implementation defines this?

Only components from the thread support library count because of these quotes, or main which the standard states runs in its own thread of execution.

1 The following subclauses describe components to create and manage threads (1.10) , perform mutual exclusion, and communicate conditions and values between threads, as summarized in Table 148.

The link to 1.10 implies that the threads being spoken about are these.

1 A thread of execution (also known as a thread) is a single flow of control within a program, including the initial ...

Therefore it seems to me threads only refer to the stdlib threads (meaning std::thread and anything the thread support library does internally). Of course thread_local in many cases could end up working with the native threads (especially when you consider on a specific system you don't usually have more than one choice for implementing threads) but as far as I can tell the standard makes no guarantee.

C++11 §1.10/1 defines the terms:

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 ]

The italicized terms indicate that this is definitive. You could argue that this definition is mathematically deficient, because each function invocation defines a new thread, but that's just obviously wrong. They mean maximal single flow of control, otherwise the non-normative note would cancel the effect of the normative "recursively including" text.

From the standpoint of the core language, it is merely incidental that std::thread causes such a thing to exist.

What if I use a library that provides user-space threads - does each of those get its own copies of thread_local objects (I don't really see how that could be implemented)?

There is no way to write such a library without kernel calls. In all likelihood all threads in your process are already represented a high-level abstraction such as pthreads, just to satisfy the kernel. The C++ standard library is likely written against the native threading library to "just work" without additional glue.

For example, thread_local objects are initialized at first access rather than when each new thread starts, so the compiler just has to insert a query based on pthread_self to access and perhaps initialize. Initialization would register a destructor with the pthread_cleanup facility.

What is implementation-defined here is whether the pre-existing native library is compatible with C++. Supposing they provide that, and it's something customers would tend to want, all other threading libraries built atop it will be automatically compatible barring some other conflict.

The standard does not describe how threads produced by other libraries and system calls behave. They are, as far as the standard is concerned, undefined in their behavior. There is no other way, within C++ proper, to create multiple threads: such libraries or system calls do things that are not standardized by the C++ standard.

Now, each such library and system call will behave in ways defined by its own specs. Quite often, the C++ std::thread will even be built on top of such libraries or system calls. How exactly the interaction works is not specified.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM