Thread: which one run first, destructor or return method

I'm not sure if this is a question of auto object management or of thread behavior. It would seem to depend on 'a', no?

Code:

#include <iostream>
#include <string>

class foo
{
   public:
       foo(std::string & s_) : s(s_) {}
       ~foo() { s = "destroyed"; }
   private:
       std::string & s;
};

std::string & test(std::string & s)
{
   foo bar(s);
   return s;
}

int main()
{
      std::string s("Not destoyed");
      std::cout << test(s) << std::endl;
}

*edit* ahh is the instance of Mutex called 'a'?

*edit* ahh is the instance of Mutex called 'a'?

i dont understand what did u mean >.<

the 'a' variable is any variable that would like to be synchronized.
usually we may write it like this :

Code:

public int Test(){
    pthread_mutex_lock(&mutex);
    int res = a; //a is class' variable
    pthread_mutex_unlock(&mutex);
   
   return a;
}

Will it be the same and safe with code below?

Code:

public int Test(){
        Mutex(mutex);
        return a;
}

I don't know enough to say. Sorry

I would think that objects go out of scope after the return statement. Otherwise if you have

Code:

X foo()
{ 
    X a, b;
    //...
    return a + b;
}

then it would be quite strange if a and b were already destructed.

I'm no good in threading, but shouldn't it actually be the caller of the function who ensures that things are locked while it is assigning or using the return value of Test()?

That should work as intended, but it doesn't seem like a good idea. You'd usually want more control over locking/unlocking and using it from the calling functions rather than lazily relying on deconstructors for the entire scope. Of course it could be put into it's own scope as well.

Code:

public int Test()
{
        {
                Mutex(mutex);

                //do something here
        }

        return a;
}

Originally Posted by Dae

That should work as intended, but it doesn't seem like a good idea. You'd usually want more control over locking/unlocking and using it from the calling functions rather than lazily relying on deconstructors for the entire scope. Of course it could be put into it's own scope as well.

Code:

public int Test()
{
        {
                Mutex(mutex);

                //do something here
        }

        return a;
}

Nio, it's actually quite common to make locking ojects that unlock on destruction - it is a good way to avoid deadlocks caused by forgetting to unlock!

--
Mats

The only question is whether the access is before or after the destruction.

The C++ standard does say something about this, I'm pretty sure, (something along the lines of "the argument to the return statement is evaluated completely before the destructors run"), but having no access to it right now, I can't verify.

Bjarne Stroustrup says: 10.4.4: A named automatic object, which is created each time its declaration is encountered in the execution of the program and destroyed each time the program exits the block in which it occurs. In this case, exiting the block happens when it has gone past the return, technically speaking.

Also, as examples have described above, if you return a + b, where a and b are local objects which gets destroyed when we leave the function, a + b would not work correctly if it's not evaluated BEFORE destruction - and this type of code is far from unusual.

--
Mats

Originally Posted by Thantos

The problem I see is that the mutex isn't a named object. Being an anonymous object might change the behavior a bit. For example, there is no reason that the object couldn't be destroyed right after it was created as there is no further use for the object.

That is a good point. It should have a name.

Oh yes, I noticed that and then forgot to post about it. The temporary must be destroyed at the end of the statement that creates it.

Originally Posted by CornedBee

Oh yes, I noticed that and then forgot to post about it. The temporary must be destroyed at the end of the statement that creates it.

Unless the temporary is assigned to a const-reference.