Asynchronous calls in C++ and MFC using boost and tbb

The alternative implementation of ICalculator interface, the one that executes the methods and the callbacks asynchronously is called CAsyncCalculator defined as follows:

typedef tbb::concurrent_queue<boost::function<void()>> CallQueue;
class CEventReceiver:public CWnd
{
public:
    CEventReceiver(CallQueue& queue);
    ~CEventReceiver();
    void QueueCall(boost::function<void()> &call);
protected:
    LRESULT OnExecuteCall(WPARAM, LPARAM);
    DECLARE_MESSAGE_MAP()
private:
    CallQueue& m_call_queue;
};

class CAsyncCalculator :
    public CWinThread,
    // Is an ICalculator
    public ICalculator,
    // Implemented in terms of ...
    private ICalculatorEvents
{
public:
    CAsyncCalculator(ICalculatorEvents&);
    ~CAsyncCalculator(void);
    // ICalculator
    bool Start(void);
    int  Add(int a, int b);
    void Factorial(unsigned int a);
    void Stop(void);
protected:
    afx_msg void OnExecuteCall(WPARAM, LPARAM);
    DECLARE_MESSAGE_MAP()
    void QueueCall(boost::function<void()> &call);
private:
    // CWinThread overrides
    BOOL InitInstance();
    int ExitInstance();
    // ICalculatorEvents
    void Started(void);
    void Stopped(void);
    void Result(int);
    void Error(int);
private:
    ICalculatorEvents& m_external_callback;
    boost::shared_ptr <ICalculator> m_calculator_impl;
    CallQueue m_call_queue;
    CallQueue m_callback_queue;
    boost::barrier m_worker_thread_started;    
    CEventReceiver m_event_receiver;
};   

Points of Interest

 Before I forget, let me say that when you use multiple inheritance in MFC, you better put the MFC class as the first one, if you don't want any surprises: 

warning C4407: cast between different pointer to member representations, compiler may generate incorrect code 

While compiling this line: 

 ON_THREAD_MESSAGE(UWM_EXECUTE_CALL, OnExecuteCall) 

CAsyncCalculator is a class derived from the ICalculator interface. We also derive it from CWinThread and Create a background thread in the constructor. This thread will execute our calls. We have a concurrent queue for the calls we need to execute on the background thread and another one for the callbacks. The callbacks need to be executed by the same thread that is calling the methods of the ICalculator interface, the same one that created the instance of CAsyncCalculator. This is where the CEventReceiver window class comes into picture, it is a message handling window created in the constructor of CAsyncCalculator that takes the callbacks and executes them.  

CAsyncCalculator::CAsyncCalculator(ICalculatorEvents& callback):
m_external_callback(callback),
m_worker_thread_started(2),
m_event_receiver(m_callback_queue)
{
    BOOL thread_created = CreateThread();
    m_worker_thread_started.wait();    
} 

We admit that this CAsyncCalculator class is a bit jammed with too many things and it does have methods that are called from two different threads, but please take it as an educational example rather than something you might want to submit for a rigorous OOP code review. 

It is important to have the instance of the contained CCalculator object created by the background thread, where all the calls to the CCalculator instance are going to be executed to, and all the callbacks are going to be fired from.

BOOL CAsyncCalculator::InitInstance()
{
    m_calculator_impl = boost::shared_ptr<ICalculator>(new CCalculator(*this));
    m_worker_thread_started.wait();
    return TRUE;
}

The implementation of ICalculator interface in CAsyncCalculator class reveals the mechanisms through which the calls are packaged and marshaled, queued to be executed on a different thread.

bool CAsyncCalculator::Start(void)
{
    boost::packaged_task<bool> task(boost::bind(&ICalculator::Start,m_calculator_impl.get()));    
    boost::unique_future<bool> f = task.get_future();
    QueueCall(MoveTaskIntoFunction<bool>(task));
    
    // Timed wait
    if (!f.timed_wait(CALL_TIMEOUT))
    {
        throw std::runtime_error("Start call timeout.");
    }
    return f.get();
} 

 Above you see that we want to execute the call in a sync fashion but have a timeout as a maximum duration we afford to wait for the execution to complete. 

MoveTaskIntoFunction is a whole story in itself and we credit D Drmmr for coming up with it. You can read more about the subject here. You needed because you want to store in the same concurrent queue tasks/functions that have different return types. 

QueueCall and OnExecuteCall looked like this: 

void CAsyncCalculator::QueueCall(boost::function<void()> &call)
{
    m_call_queue.push(call);
    PostThreadMessage(UWM_EXECUTE_CALL, 0, 0);
}
void CAsyncCalculator::OnExecuteCall(WPARAM, LPARAM)
{
    boost::function<void()> call;
    while(m_call_queue.try_pop(call))
    {        
        call();
    }
} 

The callbacks are going through a similar hijacking process where the initial callback  interface reference is being stored as a member variable m_external_callback locally and replaced with a a private implementation provided by the inheritance of the ICalculatorEvents. 

Once the callback makes it from CCalculator to CAsyncCalculator is being packaged and queued for execution by the CEventReceiver object. 

void CAsyncCalculator::Started(void)
{
    boost::packaged_task<void> task(boost::bind(&ICalculatorEvents::Started, &m_external_callback));
    m_event_receiver.QueueCall(MoveTaskIntoFunction<void>(task));
} 

This happens in the OnExecuteCall message handling method similarly with what we had in CAsyncCalculator:

LRESULT CEventReceiver::OnExecuteCall (WPARAM, LPARAM)
{
    boost::function<void()> call;
    while(m_call_queue.try_pop(call))
    {        
        call();
    }
    return NULL;
}

void CEventReceiver::QueueCall(boost::function<void()> &call)
{
    m_call_queue.push(call);
    ::PostMessage(m_hWnd, UWM_EXECUTE_CALL, 0,0);
}

It might look like a lot of code to type, but I'm sure there could be ways to shorten that.