in C++ which happens first, the copy of a return object or local object's destructors?

Question

I imagine there's an answer to this somewhere, but I couldn't find it because there are lots of threading questions, and mine's pretty simple by comparison.

I'm not trying to make a threadsafe copy or assignment constructor or anything like that.

What I'm wondering, is if I have a class that represents a mutex lock and I return from a function that instantiates it, which happens first, the destructor of my mutex (thus unlocking it) or the copy constructor of the return value. Here's my example:

string blah::get_data(void)
  {
    MutexLock ml(shared_somewhere_else); // so this locks two threads from calling get_data at the same time

    string x = "return data";
    return x;
  }

Somewhere else, we call get_data...

 string result = get_data();

Thinking back to C for a second, you never return a pointer to a global variable, because the local variable goes out of scope after you return.

C++ doesn't have this problem because x will get copied into result. What I'm wondering is when that happens. Will my lock free before the copy is made?

In this simple example "return data" is static information, but what I'm working with, it's data that can be changed by another thread (also locked on the same MutexLock) so if the lock frees before the copy-to-result is made, the copy could get corrupted.

I'm not sure I'm explaining the question well, so I'll try to clarify if this doesn't make sense.

Answer 1

For previous standards (here I will use C++ 03), the closest the standard comes to declaring the sequence of operations in a return is from 6.6

6.6 Jump statements

2. On exit from a scope (however accomplished), destructors (12.4) are called for all constructed objects with automatic storage duration (3.7.2) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration. Transfer out of a loop, out of a block, or back past an initialized variable with automatic storage duration involves the destruction of variables with automatic storage duration that are in scope at the point transferred from...

The return statement must complete in order to exit the [function] scope, implying that the copy-initialization must also complete. This order is not explicit. Various other quotes from 3.7.2 and 12.8 concisely state the same as above without providing explicit order. Working revisions (after Nov. 2014) include the quote below to address that. The defect report clarifies the change.

From the current working draft (N4527) of the standard as seen on the date of this question

6.6.3 The Return Statement

3. The copy-initialization of the returned entity is sequenced before the destruction of temporaries at the end of the full-expression established by the operand of the return statement, which, in turn, is sequenced before the destruction of local variables (6.6) of the block enclosing the return statement.

Notice that this quote refers directly to 6.6. So I think it is safe to assume that the Mutex object will always be destroyed after the return expression has copy-initialized the return value.

Answer 2

While I am no standard guru, it seems quite obvious that destructors should be called after the copy is made - otherwise the very object you are copying would be destroyed before it is copied... :)

Answer 3

The easiest way to remember the order of destruction is that it is done in the opposite order of creation at leaving the block and you leave the block after the return.

If you think about it, the latest constructed is on top of the stack, ie. the temporaries needed for the return statement, then the automatic which are in opposite order.

The return statement in this case might be an RVO or NRVO (Named Return Value Optimization) which effectively is a move. But even that is not certain due to SSO(small string optimization) which could cause it to be a new construction.

The return value is placed on the "return stack" at the end of return, before destruction. Originally it was placed on the stack and then copied around, maybe a couple of times before being assigned to the var that it was intended too. The (N)RVO makes it a bit more murky as it intent to place it at the final destination if possible.

If we look at the order of creations and destructions using as-if

Mutex     -> stack +mutex
string x  -> stack +string x base ie. length, capacity and data pointer
          -> heap  +string x data
return x  -> stack +string r base (this is a copy)
          -> heap  +string r data (this is a copy)
end block -> start destruction
destroy x -> heap  -string x data
             stack -string x base
mutex     -> stack -mutex
return to main
          -> destroy old result data
copy return value to result
          -> copy  return base to result base
          -> heap  +new result data
          -> copy  return data to result data
destroy r -> heap  -return data
          -> stack -return base

This clearly is ineffective lets turn on -O3 using italic to denote changed code

Mutex     -> stack +mutex
string x  -> stack +string x base ie. length, capacity and data pointer
          -> heap  +string x data
return x  -> *no need to copy, x is where we want it*
end block -> start destruction
destroy x -> *no need to destroy x as we need it*
mutex     -> stack -mutex
return to main
          -> destroy old result data
copy return value to result
          -> copy return base to result base
          -> *no need to copy the data as its the same*
destroy r -> heap  -return data
          -> stack *only data need to be destroyed so base is destroyed by adjusting stack pointer* 

now we can add (N)RVO which is cheating by adding the return address to the functions parameter, so get_data() becomes get_data(string& result)

*place result on stack
          -> +stack &result*
Mutex     -> stack +mutex
string x  -> *string x is not needed as we use result& *
*if new data is longer than result.capacity 
          -> destroy old data
          -> heap  +string x data
else      -> just copy it*
end block -> start destruction
mutex     -> stack -mutex
return to main
          -> *there is no old result data to destroy*
*data is already in correct position so no copy return value to result*
*there is no return value on stack so don'tdestroy it*

which leaves us with

place result on stack
          -> +stack &result
Mutex     -> stack +mutex
if new data is longer than result.capacity 
          -> destroy old data
          -> heap  +string x data
else      -> just copy it
end block -> start destruction
mutex     -> stack -mutex
return to main

Answer 4

A practical addition to Rollen D'Souza's answer.

So now we have a quote from the standard. Now, how does it look like in real code?

Disassembly (VS2015, Debug mode) of this code :

#include <thread>
#include <mutex>
#include <iostream>


std::mutex g_i_mutex;

std::string get_data() {
    std::lock_guard<std::mutex> lock(g_i_mutex);
    std::string s = "Hello";
    return s;
}

int main() {
    std::string s = get_data();
}

...shows:

     8: std::string get_data() {
 push        ebp  
 mov         ebp,esp  
 push        0FFFFFFFFh  
 push        0A1B6F8h  
 mov         eax,dword ptr fs:[00000000h]  
 push        eax  
 sub         esp,100h  
 push        ebx  
 push        esi  
 push        edi  
 lea         edi,[ebp-10Ch]  
 mov         ecx,40h  
 mov         eax,0CCCCCCCCh  
 rep stos    dword ptr es:[edi]  
 mov         eax,dword ptr ds:[00A21008h]  
 xor         eax,ebp  
 mov         dword ptr [ebp-10h],eax  
 push        eax  
 lea         eax,[ebp-0Ch]  
 mov         dword ptr fs:[00000000h],eax  
 mov         dword ptr [ebp-108h],0  
     9:     std::lock_guard<std::mutex> lock(g_i_mutex);
 push        0A212D0h  
 lea         ecx,[lock]  
 call        std::lock_guard<std::mutex>::lock_guard<std::mutex> (0A11064h)  
 mov         dword ptr [ebp-4],0  
    10:     std::string s = "Hello";
 push        0A1EC30h  
 lea         ecx,[s]  
 call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (0A112A8h)  
    11:     return s;
 lea         eax,[s]  
 push        eax  
 mov         ecx,dword ptr [ebp+8]  
 call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (0A110CDh)  
 mov         ecx,dword ptr [ebp-108h]  
 or          ecx,1  
 mov         dword ptr [ebp-108h],ecx  
 lea         ecx,[s]  
 call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (0A11433h)  
 mov         dword ptr [ebp-4],0FFFFFFFFh  
 lea         ecx,[lock]  
 call        std::lock_guard<std::mutex>::~lock_guard<std::mutex> (0A114D8h)  
 mov         eax,dword ptr [ebp+8]  
    12: }
 push        edx  
 mov         ecx,ebp  
 push        eax  
 lea         edx,ds:[0A1642Ch]  
 call        @_RTC_CheckStackVars@8 (0A114BFh)  
 pop         eax  
 pop         edx  
 mov         ecx,dword ptr [ebp-0Ch]  
 mov         dword ptr fs:[0],ecx  
 pop         ecx  
 pop         edi  
 pop         esi  
 pop         ebx  
 mov         ecx,dword ptr [ebp-10h]  
 xor         ecx,ebp  
 call        @__security_check_cookie@4 (0A114E7h)  
 add         esp,10Ch  
 cmp         ebp,esp  
 call        __RTC_CheckEsp (0A1125Dh)  
 mov         esp,ebp  
 pop         ebp  
 ret

The copy constructor in interest appears to be a first call after 11: return s;. We can see that this call is performed before any of the destructors (and destruction is in turn is in order reversed to order of construction).