Will C++ ever add a thread pool as part of its STL?

[MutantJohn]

I'd like to see that. Do you guys think we'll see it sometime in the future? It'd be really, really, really nice.

[Yarin]

Maybe, but probably not. Very few applications need it, and for those a library can be used.

C & C++ aren't really your batteries-included kind of languages. I personally like it that way. There are many other languages to choose from for that.

[MutantJohn]

Considering how std::thread was added recently, I don't think it'd be too much of a stretch to request from the STL people to implement a thread pool. I know boost has one but when I've compiled with boost in the past, it increased compilation times by like 10.

[Yarin]

On second thought, Go's popularity is in large part due to it's gimmick being native thread pooling, so maybe the C++ Working Group will take notice of this and eventually add it after all.

[Elysia]

I've heard no such proposal, so I find it unlikely. But maybe you can ask over at the official forums as to judge interest in people. Maybe someone will write up a proposal for it.

Considering how std::thread was added recently, I don't think it'd be too much of a stretch to request from the STL people to implement a thread pool. I know boost has one but when I've compiled with boost in the past, it increased compilation times by like 10.

Use precompiled headers.

[brewbuck]

Well, the authors of the C++ standard seem dead-set on keeping anything out of the standard that might actually be useful for implementing real world applications, so my hunch is no, they are never going to give you that.

User interface, audio, video, networking, multithreaded processing... these are but trifles. Nothing a True Programmer would ever want to concern him/herself with. Leave the implementation of those to the unwashed masses. Come back when you want to talk about something useful, like making a list of things. You know, a Real Programming Topic.

[phantomotap]

User interface, audio, video, networking, multithreaded processing... these are but trifles. Nothing a True Programmer would ever want to concern him/herself with. Leave the implementation of those to the unwashed masses. Come back when you want to talk about something useful, like making a list of things. You know, a Real Programming Topic.

O_o

You can't really blame the standard committee.

A standard that doesn't see adoption is worthless. A standard that uses primitives as designed, for example, by IBM ("ICU") isn't going to see adoption as a standard provided by Apple or Microsoft distribution. (Developers for the "iOS" platform can't even get Apple to universally expose access to the internal stack for use by "Appstore" applications.) The standard committee can't even get any sort of commitment to support primitives designed by a robust community ("Boost") without sacrificing bits to politic. Look at the history of components like `std::locale', `std::atomic<???>', or any trait requiring compiler support.

We should have more sophisticated locales, simpler atomic primitives, and a much larger traits package. The standard committee members has largely agreed, over the years, on a way forward for all of these components to a superior C++ standard library. We can thank the interested vendors for saying "Can't we have something just bit different? We want to conform to the standard, but we can't do what you suggest. We can do and also suggest something different.". You get enough vendors angling for different avenues... better by far to give a component a miss than delay the standard by years trying to make everyone building the compilers happy.

Soma

[brewbuck]

We can thank the interested vendors for saying "Can't we have something just bit different? We want to conform to the standard, but we can't do what you suggest. We can do and also suggest something different.". You get enough vendors angling for different avenues... better by far to give a component a miss than delay the standard by years trying to make everyone building the compilers happy.

The paradox is that the standard is simultaneously held to be important and treated as unimportant by the same people. Vendors want to say they conform, but then turn around and release non-conforming toolchains. I think there is a cult built up around standards conformance which drives an extremist viewpoint of all or nothing. If we took a more realistic view of the standard as something we are constantly striving to support, but admit that we don't currently get it exactly right, at least we could make progress defining the next iteration and subsequent ones.

I still can't use basic features of the language on many platforms I target, and I don't really expect that to ever change. But by waiting for that conformance to happen, which it won't, the "big" toolchains have to go without perfectly useful standard language features because nobody can decide to standardize them.

Oh well, it's how it is. I just get tired of continually explaining to people why you can't actually write useful software while sticking to the standard.

[MutantJohn]

It's just, with the advent of std::thread and lambdas, making a thread pool shouldn't be that hard to standardize, right?

I'm not sure how it would be done but couldn't you just create a std::vector<std::thread> threadpool and then construct some number of threads with each thread listening on an unused and unique port? Then couldn't you just pass functions to the container which would then send the data to the appropriate port?

Or is that not how it would work? I'm a super duper network newb but I read that in the most generic sense, a servers and sockets are just inter-process communications so to put a thread in a "wait" state, it should just be listening on a port for incoming data.

Edit :

std::vector<std::thread> pool;
pool.reserve(n);

for (int i = 0; i < n; ++i)
{
    pool.emplace_back([](){
        // begin listening on port blah blah blah
    });
}

[phantomotap]

I think there is a cult built up around standards conformance which drives an extremist viewpoint of all or nothing.

O_o

You are correct. I am, after a fashion, one of those cult members.

Until 2013, my library code could have features conditionally compiled with compilers older than the standard. (I would have made the change earlier, but I had some health issues.) I've not meaningfully changed the code in many ways. I still use subset of standard C++98 for most of my work. I just offer C++11 features with conditionally compiled code where those features are available.

If we took a more realistic view of the standard as something we are constantly striving to support, but admit that we don't currently get it exactly right, at least we could make progress defining the next iteration and subsequent ones.

I've advocated, now for six years I think, to add many more levels to the standard. The standard already has "hosted" and "freestanding" to reduce the burden on vendors to provide libraries which may extraneous while still being able to claim conformance to the core. I see infinite value in adding "interface", "network", and "internationalization" layers allowing vendors to provide only those recommended components which they find necessary. I've seen many arguments against such additional layers, buy I believe my arguments to be superior. Competition. If we could get the committee to support governance of the optional components for a few short years, the competition from a few vendors would almost certainly impose a practical requirement for those components.

I have even have evidence to support for my argument for the additional layers. Many vendors flatly refused to support most of the C++11 core additions. To be brief, conforming support for variadic templates would have been as rare as conforming support for `export' templates. Once Microsoft changed lanes several vendors, some who didn't even have strong C++98 conformance, pledged to support many more C++11 code additions. We now have, still experimental as derived from "Clang", C++11 compilers for embedded targets that previously didn't even have template support as recently as 2012.

I just get tired of continually explaining to people why you can't actually write useful software while sticking to the standard.

That depends on what you are saying.

If you are talking about core language features, you are wrong. The majority of my code conforms to a reduced subset of the C++98 standard.

If you are talking about other libraries, you are correct. I've met these people. They are idiots who should be ignored.

Soma

[phantomotap]

It's just, with the advent of std::thread and lambdas, making a thread pool shouldn't be that hard to standardize, right?

O_o

Did you read my post?

Politics!

Which flavor of pools do you implement? Do you wrap externally shared resources with a locking mechanism internally? Do you dispatch exceptions to the owner of the pool? Do you swallow resource from expired tasks?

I could ask question until your eyes bleed, and every questions has an answered choking on politics.

Seriously, the committee has no object answer for many questions so vendors will each give subject answers that mostly benefit only themselves.

[Edit]
I'm... going to stop talking.

I just did a search, and I have ranted about the politics of standardizing a developed language well too many times.
[/Edit]

Soma

[Elysia]

User interface, audio, video, networking, multithreaded processing... these are but trifles.

To be fair... network is on its way, based on boost asio. There's a study group for graphics, too. Don't know exactly what it will encompass, but maybe we can hope.
Multithreaded processing... well, that's a big area. What is it you're expecting to see? C++17 will likely see many more features related to parallel computation and concurrency.
UI we'll probably never see unless the standard committee grows exponentially in size and has some people working full-time on the committee. Haven't heard anything about audio, though.

MutantJohn: A thread pool could be as easy as maintaining a vector of function objects and starting up threads equal to the number of logical cores in the system. Then each thread would lock, pop, unlock, run. Any threads could also add a new function object to the queue. The biggest problem with this approach is if some thread blocks (e.g. locks, events, etc). With few threads running at the same time, this should be good enough for most things, I guess. Unfortunately the standard doesn't accept "good enough." It wants zero-overhead or down-to-the-metal approaches. That complicates things.

[grumpy]

It wants zero-overhead or down-to-the-metal approaches. That complicates things.

That's a bit of an exaggeration. The philosophy in the standardisation process is to avoid overhead of features within a program unless those features are used. They will accept overhead if the benefit of the feature is judged sufficient to warrant accepting that overhead. Of course, that is rather subjective, since committee members need to agree on what is "sufficient".

That is what happened in early days of exceptions, for example - early implementations of exception handling were far from zero overhead, whether exceptions were used or not. That has changed on two fronts. Firstly, the overhead of exceptions is much smaller in modern implementations - most of the observable impact on program performance occurs when the exception is thrown/caught. Second, exception handling is used by default now (e.g. operator new throws unless a nothrow version is used, exceptions are used within the standard library to report errors and constraints are now specified on what happens when an exception is thrown). Which often means that, when using standard library facilities, there is an implicit choice by the programmer to utilise exceptions.

(Note that executable file size is mostly not a measure of overhead in this sense).