It just seems strange to me that despite having a very large set of constructs for multithreading, the standard lacks a thread pool class. What reasons might dissuade the committee from adding this to the standard?

- 8,038
- 2
- 40
- 58

- 1,803
- 2
- 17
- 27
-
1And what exact characteristics should this type have, beside the name? – StoryTeller - Unslander Monica Nov 08 '19 at 22:11
-
1[you can look here](https://stackoverflow.com/questions/12993451/c11-stdthread-pooled) – Mert Köklü Nov 08 '19 at 22:12
-
@Marceline I read that before I posted this question. But that question answers if std::thread is pooled, which has a clear yes/no answer. My question is different. – Hisham Hijjawi Nov 08 '19 at 22:18
-
@StoryTeller-UnslanderMonica Just a general purpose thread pool along the lines of boost::thread_pool was my idea. The committee already has added a lot of boost's threading constructs to the standard, so I don't see why something this big wasn't added. – Hisham Hijjawi Nov 08 '19 at 22:21
-
A `std::static_thread_pool` is part of the current broader executors proposal. see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0443r11.html – walnut Nov 08 '19 at 22:29
-
To a certain extent `std::async` is a thread pool. getting everyone to agree on what a full blown thread pool should look like is probably quite difficult – Alan Birtles Nov 08 '19 at 22:30
-
The explanations of why any feature is not in the standard could be as simple as "the committee hasn't got around to it yet" or as complicated as "committee members haven't agreed yet that it is needed, or how to specify it". Development of the standard is a consensus-based process involving a committee, and there are numerous pending proposals. The process doesn't just allow for features to be tipped in because a few people think it is a good idea - there is a whole process of proposing changes, agreeing on need, agreeing on how to do it, etc - and that takes time. – Peter Nov 08 '19 at 23:08
-
@Peter Yeah, I guess democratic committee can be slow sometimes. Java has had a a thread pool class (Executor Service) for 10 years now, so I'm just a bit surprised that it has taken this long. – Hisham Hijjawi Nov 08 '19 at 23:20
-
@user3586940 - Standard C++ didn't include threading *at all* until 2011 - multi-threaded development before then relied on vendor-specific extensions. C++ and Java are very different languages, and the ways they evolve are quite different - and each has capabilities the other does not. Saying "but Java does it" does not mean that C++ can (or even should) do it. Similarly, saying "but C++ can do that" doesn't mean that Java can/should do it. – Peter Nov 09 '19 at 00:06
-
@Peter Java "does it" (the spec promises it) at least can be used to show that either 1) smthg is implementable on common hardware, or 2) the Java ppl promised too much and either 2a) they don't care, or 2b) they didn't notice it yet, or 2c) they have no found the time to fix it. You should be vary of the idea that Java is portable and that following the spec provides hard guarantees. – curiousguy Nov 10 '19 at 09:34
-
@curiousguy - I made no such suggestions. – Peter Nov 10 '19 at 10:20
-
@Peter You seemed to suggest that Java has a thread semantics. – curiousguy Nov 10 '19 at 10:28
-
@curiousguy - I responded to a comment by the OP which essentially queried why C++ doesn't support an implementation of thread pools, despite Java having had one for over ten years. – Peter Nov 10 '19 at 10:39
-
@AlanBirtles `std::async` is not a thread pool. It either runs some "task" in a newly-created thread or synchronously. There is no option how to create a desired fixed number of threads only, which is an important characteristic of thread pools. – Daniel Langr Dec 16 '21 at 19:28
-
@DanielLangr i did say `To a certain extent`, the implementation could well use a pool rather than creating new threads for each task, I'm not sure that any implementations do that but they could of they wanted to – Alan Birtles Dec 16 '21 at 20:32
-
@AlanBirtles There are some discussions about whether using a thread pool with `std::async` is valid. I have mostly seen the opinion that it is actually not. There is that formulation "as if in a new thread of execution" in the standard. The problem then is, for instance, with _thread-local_ variables that should be local for each `async` call that uses the async policy. But yes, I think in Microsoft STL, `async` really uses a thread pool internally. Which might be non-conformant. – Daniel Langr Dec 17 '21 at 08:31
-
Does this answer your question? [Why is there no thread pool in C++ standard library?](https://stackoverflow.com/questions/69191676/why-is-there-no-thread-pool-in-c-standard-library) – Keith Russell Oct 24 '22 at 14:27
1 Answers
C++, like C, is meant to give as much control to the programmer as possible. Almost everything in C++ is a wrapper that is very bare-bones. This give the programmer freedom to implement whatever feature they want however they want.
The concept of "what is work" is a bit abstract and dependent on the use case, so C++ gives you the workers (threads), and lets you define a strategy for how you want that work to be distributed amongst the workers.
For example, in Python, you can map work to threads. Using this means that whenever work is available, a thread will take the work. But what if you want a thread to only do work if there is work to do AND after certain conditions are met. You can design your thread_pool class to meet all these specifications. In Python, you'd have to handle these checks separately outside of the thread pooling library.
While there is no OFFICIAL answer, this is the answer that I would say makes more sense. C++ is about control given a minimal amount of tools (however an EXTENDED set compared to C). The committee is most likely not adding a thread_pool class because the hardest thing to do in Computer Science is getting people to agree. Thread pooling is not necessarily extremely hard to implement, and defining a definition of worker is arguably harder.

- 105
- 2
- 9
-
`std::async` is implemented as a thread pool in VS2019. It's often much faster than spinning new threads but isn't strictly compatible with the standard since static local construction/destruction differs from spinning unique threads. – doug Nov 09 '19 at 02:13