Concurrency-safe stack interface method: correct or not? - c++

Question

I came across a thread-safe stack implementation of an interface method for stack<>::pop():
void pop(T& value)
{
std::lock_guard<std::mutex> lock(m);
if(data.empty()) throw empty_stack();
value=std::move(data.top()); <----- why not just value = data.top()?
data.pop();
}
Granted, my question has nothing to do with concurrency, but why MOVE the value at the top of the stack into variable value? My understanding is once it is moved, you can't pop it as it is no longer there.
Either it is a mistake in the source where I found it, or if someone can explain it to me I would be thankful.
Thanks,
Amine

Answer 1

value=std::move(data.top()); <----- why not just value = data.top()?
This largely depends on what T is, basically it is going to try and use the move constructor, T(T &&mv) instead of the copy constructor T(const T &cp) if the move constructor exists.
In both cases ~T() will be called for the original object on the data.pop(); line.
Firstly, using the move constructor might be required. Some objects are moveable, but not copyable, e.g. a unique_ptr.
Secondly, where move is provided, it is often more efficient. e.g. say T is a std::vector, the copy constructor will allocate another array and then copy over each element (which might also be expensive), and then it deletes the original array anyway. Which is pretty wasteful.
A move constructor just keeps the original elements by moving the internal data array from one vector to a new one, and leaves the original (which is about to be deleted anyway in this case) in an unspecified but valid state (probably "empty").
It might look something like:
template<typename T> class vector
{
public:
vector<T>(vector<T> &&mv)
: arr(mv.arr) , arr_len(mv.arr_len), arr_capacity(mv.arr_capacity)
{
mv.arr = nullptr;
mv.arr_len = 0;
mv.arr_capacity = 0;
}
...
private:
T *arr;
size_t arr_len;
size_t arr_capacity;
};
Since the original object state is "unspecified" in the general case if you want to keep using the original object, you have to be careful. Destroying it as in the pop case is OK, as is assignment.
T tmp = std::move(some_value);
some_value.foo(); // In general, what state some_value is in is unknown, this might vary even from compiler to compiler
some_value = some_other_value; // But assignment should work
some_value.foo(); // So it is now in a known state
Which can implement for example a "swap" without copying any "contents" where possible.
template<typename T> void swap(T &a, T &b)
{
T tmp = std::move(a);
a = std::move(b);
b = std::move(tmp);
}
Many types will be more specified, for example for std::vector, it promises to be empty().
std::vector<T> tmp = std::move(some_array);
assert(some_array.empty()); // guaranteed
some_array.push_back(x); // guaranteed to have one element
you can't pop it as it is no longer there.
So the important bit here is that data.top() does not remove the element, so it is still there. And the move doesn't actually delete the thing, just leaves it in some unspecified state.
Concurrency-safe stack interface method
On the separate subject of concurrency the thing here is both the top to access the value, and the pop to remove it are under the same lock. To be safe all accesses to this instance stack must use that same lock instance, so make sure any data.push also holds the lock.