Cannot construct tuple from atomic object in C++ - c++

Question

I am new to atomic in C++ and trying to make a tuple from atomic objects. I am getting a compile time error and I do not understand why. How can I resolve the error?
Created this test program
int main()
{
std::atomic<double> a1{0};
std::atomic<double> a2{0};
std::atomic<double> a3{0};
// Parallel processing
ParallelFor(...) {
// update atomic variables.
}
std::make_tuple(a1,a2,a3);
return 0;
}
Compile time error:
In instantiation of 'constexpr std::tuple<typename std::__decay_and_strip<_Elements>::__type ...> std::make_tuple(_Elements&& ...) [with _Elements = {std::atomic<double>&, std::atomic<double>&, std::atomic<double>&}]':
progatomic.cpp:17:26: required from here
error: no matching function for call to 'std::tuple<std::atomic<double>, std::atomic<double>, std::atomic<double> >::tuple(std::atomic<double>&, std::atomic<double>&, std::atomic<double>&)'
return __result_type(std::forward<_Elements>(__args)...);
Thanks

Answer 1

The code has two rules applied that are causing the problem:
Type inferencing: You're using std::make_tuple with type-inference, so it's trying to make a tuple templated on the type of the arguments (std::tuple<std::atomic<double>, std::atomic<double>, std::atomic<double>>), copying from the arguments
Non-copyable types: std::atomic is non-copyable
There are at least three different ways to fix this:
If you want a tuple of references to the original std::atomics, use std::tie, e.g. std::tie(a1, a2, a3). No actual data is read from the atomics, so you won't get any complaints, but the tuple will now contain references to std::atomic<double>s that may keep changing.
If you want a tuple of the values currently in the atomics (which will be extracted in an unspecified order, since C++ makes no guarantees on the order in which arguments are evaluated, and therefore you can't guarantee any particular ordering of results if another thread is still modifying them), do one of two things so std::make_tuple knows it's making copies of the actual double values, not the atomics themselves, either:
Explicitly load from the variables: std::make_tuple(a1.load(), a2.load(), a3.load()). For efficiency, since sequential consistency can't actually guarantee the order the arguments are loaded in, you might want to relax the memory ordering requirements explicitly, with std::make_tuple(a1.load(std::memory_order_acquire), a2.load(std::memory_order_acquire), a3.load(std::memory_order_acquire)), or even std::memory_order_relaxed instead. Technically, if the values were stored without std::memory_order_release or stronger, dropping to acquire might allow you to see inconsistent state for non-atomics, but if that's an issue, you could use:
std::make_tuple(a1.load(std::memory_order_relaxed), a2.load(std::memory_order_relaxed), a3.load(std::memory_order_relaxed));
std::atomic_thread_fence(std::memory_order_seq_cst);
to get the best of both worlds; no wasted work per load, just a single fence to guarantee nothing written prior to those loads is missed when non-atomics are read afterwards.
Explicitly template make_tuple so it implicitly casts to the underlying value type, rather than inferring std::atomic<double>: std::make_tuple<double, double, double>(a1, a2, a3) (downside: Since the load is now implicit, you can't relax the memory ordering; three memory fences are going to be involved)
The two approaches are fixing one of the two issues from above, either removing type inference through explicit templating (preserving implicit loads), or removing copying through explicit loads that convert to a copyable type (preserving implicit templating). Either one (or both) would solve the problem, because the problem only occurs when both type-inferencing and non-copyable types are involved.