C ++ 11中的异步构造函数

Question

Sometimes I need to create objects whose constructors take very long time to execute. This leads to responsiveness problems in UI applications.

So I was wondering if it could be sensible to write a constructor designed to be called asynchronously, by passing a callback to it which will alert me when the object is available.

Below is a sample code:

class C
{
public:
    // Standard ctor
    C()
    {
        init();
    }

    // Designed for async ctor
    C(std::function<void(void)> callback)
    {
        init();
        callback();
    }

private:
    void init() // Should be replaced by delegating costructor (not yet supported by my compiler)
    {
        std::chrono::seconds s(2);
        std::this_thread::sleep_for(s);
        std::cout << "Object created" << std::endl;
    }
};

int main(int argc, char* argv[])
{
    auto msgQueue = std::queue<char>();
    std::mutex m;
    std::condition_variable cv;
    auto notified = false;

    // Some parallel task
    auto f = []()
    {
        return 42;
    };

    // Callback to be called when the ctor ends
    auto callback = [&m,&cv,&notified,&msgQueue]()
    {
        std::cout << "The object you were waiting for is now available" << std::endl;
        // Notify that the ctor has ended
        std::unique_lock<std::mutex> _(m);
        msgQueue.push('x');
        notified = true;
        cv.notify_one();
    };

    // Start first task
    auto ans = std::async(std::launch::async, f);

    // Start second task (ctor)
    std::async(std::launch::async, [&callback](){ auto c = C(callback); });

    std::cout << "The answer is " << ans.get() << std::endl;

    // Mimic typical UI message queue
    auto done = false;
    while(!done)
    {
        std::unique_lock<std::mutex> lock(m);
        while(!notified)
        {
            cv.wait(lock);
        }
        while(!msgQueue.empty())
        {
            auto msg = msgQueue.front();
            msgQueue.pop();

            if(msg == 'x')
            {
                done = true;
            }
        }
    }

    std::cout << "Press a key to exit..." << std::endl;
    getchar();

    return 0;
}

Do you see any drawback in this design? Or do you know if there is a better approach?

Following the hints of JoergB's answer, I tried to write a factory which will bear the responsibility to create an object in a sync or async way:

template <typename T, typename... Args>
class FutureFactory
{
public:
    typedef std::unique_ptr<T> pT;
    typedef std::future<pT> future_pT;
    typedef std::function<void(pT)> callback_pT;

public:
    static pT create_sync(Args... params)
    {
        return pT(new T(params...));
    }

    static future_pT create_async_byFuture(Args... params)
    {
        return std::async(std::launch::async, &FutureFactory<T, Args...>::create_sync, params...);
    }

    static void create_async_byCallback(callback_pT cb, Args... params)
    {
        std::async(std::launch::async, &FutureFactory<T, Args...>::manage_async_byCallback, cb, params...);
    }

private:
    FutureFactory(){}

    static void manage_async_byCallback(callback_pT cb, Args... params)
    {
        auto ptr = FutureFactory<T, Args...>::create_sync(params...);
        cb(std::move(ptr));
    }
};

Answer 1

Your design seems very intrusive. I don't see a reason why the class would have to be aware of the callback.

Something like:

future<unique_ptr<C>> constructedObject = async(launchopt, [&callback]() {
      unique_ptr<C> obj(new C());
      callback();
      return C;
})

or simply

future<unique_ptr<C>> constructedObject = async(launchopt, [&cv]() {
      unique_ptr<C> ptr(new C());
      cv.notify_all(); // or _one();
      return ptr;
})

or just (without a future but a callback taking an argument):

async(launchopt, [&callback]() {
      unique_ptr<C> ptr(new C());
      callback(ptr);
})

should do just as well, shouldn't it? These also make sure that the callback is only ever called when a complete object is constructed (when deriving from C).

It shouldn't be too much effort to make any of these into a generic async_construct template.

Answer 2

Encapsulate your problem. Don't think about asynchronous constructors, just asynchronous methods which encapsulate your object creation.

Answer 3

It looks like you should be using std::future rather than constructing a message queue. std::future is a template class that holds a value and can retrieve the value blocking, timeout or polling:

std::future<int> fut = ans;
fut.wait();
auto result = fut.get();

Answer 4

I will suggest a hack using thread and signal handler.

1) Spawn a thread to do the task of the constructor. Lets call it child thread. This thread will intialise the values in your class.

2) After the constructor is completed, child thread uses the kill system call to send a signal to the parent thread. (Hint : SIGUSR1). The main thread on receiving the ASYNCHRONOUS handler call will know that the required object has been created.

Ofcourse, you can use fields like object-id to differentiate between multiple objects in creation.

Answer 5

My advice...

Think carefully about why you need to do such a long operation in a constructor.

I find often it is better to split the creation of an object into three parts

a) allocation b) construction c) initialization

For small objects it makes sense to do all three in one "new" operation. However, heavy weight objects, you really want to separate the stages. Figure out how much resource you need and allocate it. Construct the object in the memory into a valid, but empty state.

Then... do your long load operation into the already valid, but empty object.

I think I got this pattern a long time ago from reading a book (Scott Myers perhaps?) but I highly recommend it, it solves all sorts of problems. For example, if your object is a graphic object, you figure out how much memory it needs. If it fails, show the user an error as soon as possible. If not mark the object as not read yet. Then you can show it on screen, the user can also manipulate it, etc. Initialize the object with an asynchronous file load, when it completes, set a flag in the object that says "loaded". When your update function sees it is loaded, it can draw the graphic.

It also REALLY helps with problems like construction order, where object A needs object B. You suddenly find you need to make A before B, oh no!! Simple, make an empty B, and pass it as a reference, as long as A is clever enough to know that be is empty, and wait to it is not before it uses it, all is well.

And... Not forgetting.. You can do the opposite on destruction. Mark your object as empty first, so nothing new uses it (de-initialisation) Free the resources, (destruction) Then free the memory (deallocation)

The same benefits apply.

Answer 6

Having partially initialized objects could lead to bugs or unnecessarily complicated code, since you would have to check whether they're initialized or not.

I'd recommend using separate threads for UI and processing, and then use message queues for communicating between threads. Leave the UI thread for just handling the UI, which will then be more responsive all the time.

Place a message requesting creation of the object into the queue that the worker thread waits on, and then after the object has been created, the worker can put a message into UI queue indicating that the object is now ready.

Answer 7

Here's yet another pattern for consideration. It takes advantage of the fact that calling wait() on a future<> does not invalidate it. So, as long you never call get(), you're safe. This pattern's trade-off is that you incur the onerous overhead of calling wait() whenever a member function gets called.

class C
{
    future<void> ready_;

public:
    C()
    {
        ready_ = async([this]
        {
            this_thread::sleep_for(chrono::seconds(3));
            cout << "I'm ready now." << endl;
        });
    }

    // Every member function must start with ready_.wait(), even the destructor.

    ~C(){ ready_.wait(); }

    void foo()
    {
        ready_.wait();

        cout << __FUNCTION__ << endl;
    }
};

int main()
{
    C c;

    c.foo();

    return 0;
}