CODEWITHSUNDEEP
c++multithreadingasynchronousconcurrency
thp9
thp9

Reputation: 376

Destructors and asynchronous tasks

I have a class which calls an asynchronous task using std::async in his constructor for loading its content. ( I want the loading of the object done asynchronously )

The code looks like this:

void loadObject(Object* object)
{
 // ... load object
}

Object::Object(): 
{
    auto future = std::async(std::launch::async, loadObject, this);
}

I have several instances of these objects getting created and deleted on my main thread, they can get deleted any time, even before their loading has finished.

I'd like to know if it is dangerous to having object getting destroyed when it is still getting handled on another thread. And how can I stop the thread if the object gets destroyed ?

EDIT: The std::future destructor does not block my code with the VS2013's compiler that I am using due to a bug.

Upvotes: 2

Views: 3447

Answers (3)

Lol4t0
Lol4t0

Reputation: 12547

Yes it is dangerous to having object getting destroyed when it is still getting handled on another thread

You can implement a lot of strategies actually depending on requirements and desired behaviour.

I would implement sort of pimpl strategy here, that means that all actual data will be stored in the pointer that your object holds. You will load all the data to the data-pointer-object and store it in the public-object atomically.

Techincally speaking object should be fully constrcuted and ready to use by the time the constrcutor is finished. In your case data-pointer-object will still probably be not ready to use. And you should make your class to handle correctly that state.

So here we go:

class Object
{
   std::shared_ptr<Object_data> d;
   Object::Object(): 
      d(std::make_shared<Object_data>())
   {
        some_futures_matser.add_future(std::async(std::launch::async, loadObject, d));

   }
}

Then you make atomic flag in your data-object that will signal that loading is complete and object is ready to use.

class Object_data
{
    // ...
    std::atomic<bool> loaded {false};
};

loadObject(std::shared_ptr<Object_data> d)
{
    /// some load code here
    d->loaded = true;
}

You have to check if your object is constrcuted every time when you acces it (with thread safe way) through loaded flag

Upvotes: -1

eerorika
eerorika

Reputation: 238281

As MikeMB already mentioned, your constructor doesn't finish until the load has been completed. Check this question for how to overcome that: Can I use std::async without waiting for the future limitation?

I'd like to know if it is dangerous to having object getting destroyed when it is still getting handled on another thread.

Accessing object's memory after deletion is certainly dangerous, yes. The behaviour will be undefined.

how can I stop the thread if the object gets destroyed ?

What I recommend you to take care of first, is to make sure that the object doesn't get destroyed while it's still being pointed at by something that is going to use it.

One approach is to use a member flag signifying completed load that is updated in the async task and checked in the destructor and synchronize the access with a condition variable. That will allow the destructor to block until the async task is complete.

Once you've managed to prevent the object from being destroyed, you can use another synchronized member flag to signify that the object is being destroyed and skip the loading if it's set. That'll add synchronization overhead but may be worth it if loading is expensive.

Another approach which avoids blocking destructor is to pass a std::shared_ptr to the async task and require all Object instances to be owned by a shared pointer. That limitation may not be very desireably and you'll need to inherit std::enable_shared_from_this to get the shared pointer in the constructor.

Upvotes: 4

MikeMB
MikeMB

Reputation: 21126

There is nothing asynchronous happening in your code, because the constructor blocks until loadObject() returns (The destructor of a future returned by std::async implicitly joins).

If it would not, it would depend on how you have written your code (and especially your destructor), but most probably, your code would incur undefined behavior.

Upvotes: 3

Related Questions