What's the most efficient way to return a value from a thread in C++11?
vector<thread> t(6);
for(int i = 0; i < 6; i++)
t[i] = thread(do_c);
for(thread& t_now : t)
t_now.join();
for(int i = 0; i < 6; i++)
cout << /*the return of function do_c*/
Also, if the change will benefit performance, feel free to recommend another thread than std::thread.
First of all std::thread doesn't return a value, but the function that is passed to it on construction may very well do it.
There's no way to access the function's return value from the std::thread object unless you save it somehow after calling the function on the thread.
A simple solution would e.g. be to pass a reference to the thread and store the result in the memory pointed to by the reference. With threads though one must be careful not to introduce a data race.
Consider a simple function:
int func() {
return 1;
}
And this example:
std::atomic<int> x{0}; // Use std::atomic to prevent data race.
std::thread t{[&x] { // Simple lambda that captures a reference of x.
x = func(); // Call function and assign return value.
}};
/* Do something while thread is running... */
t.join();
std::cout << "Value: " << x << std::endl;
Now, instead of dealing with this low level concurrency stuff yourself you can use the Standard Library as someone (as always) has already solved it for you. There's std::packaged_task and std::future which is designed to work with std::thread for this particular type of issue. They should also be just as efficient as the custom solution in most cases.
Here's an equivalent example using std::packaged_task and std::future:
std::packaged_task<int()> task{func}; // Create task using func.
auto future = task.get_future(); // Get the future object.
std::thread t{std::move(task)}; // std::packaged_task is move-only.
/* Do something while thread is running... */
t.join();
std::cout << "Value: " << future.get() << std::endl; // Get result atomically.
Don't always assume something is less efficient just because it is considered as "high level".
Lauching a thread and terminating it require many hundreds of machine cycles. But that's only a beginning. Context switches between threads, that are bound to happen if the threads are doing anything useful, will repeatedly consume even more many hundreds of machine cycles. The execution context of all these threads will consume many a byte of memory, which in turn will mess up many a line of cache, thus hindering the CPU efforts for yet another great deal of many hundreds of machine cycles.
As a matter of fact, doing anything with multitasking is a great consumer of many hundreds of machine cycles. Multitasking only becomes profitable in terms of CPU power usage when you manage to get enough processors working on lumps of data that are conceptually independent (so parallel processing won't threaten their integrity) and big enough to show a net gain compared with a monoprocessor version.
In all other cases, multitasking is inherently inefficient in all domains but one: reactivity. A task can react very quickly and precisely to an external event, that ultimately comes from some external H/W component (be it the internal clock for timers or your WiFi/Ethernet controller for network traffic).
This ability to wait for external events without wasting CPU is what increases the overall CPU efficiency. And that's it.
In terms of other performance parameters (memory consumption, time wasted inside kernel calls, etc), launching a new thread is always a net loss.
In a nutshell, the art of multitasking programming boils down to:
Multiprocessor architectures are adding a new level of complexity, since any program can now be seen as a process having a number of external CPUs at hand, that could be used as additional power sources. But your problem does not seem to have anything to do with that.
A measure of multitasking efficiency will ultimately depend on the number of external events a given program is expected to cope with simultaneously and within a given set of reactivity limits.
At last I come to your particular question.
To react to external events, launching a task each time a new twig or bit of dead insect has to be moved around the anthill is a very coarse and inefficient approach.
You have many powerful synchronization tools at your disposal, that will allow you to react to a bunch of asynchronous events from within a single task context with (near) optimal efficiency at (virtually) no cost.
Typically, blocking waits on multiple inputs, like for instance the unix-flavoured select() or Microsoft's WaitForMultipleEvents() counterpart.
Using these will give you a performance boost incomparably greater than the few dozen CPU cycles you could squeeze out of this task-result-gathering-optimization project of yours.
So my answer is: don't bother with optimizing thread setup at all. It's a non-issue.
Your time would be better spent rethinking your architecture so that a handful of well thought out threads could replace the hordes of useless CPU and memory hogs your current design would spawn.
