C++ MFC Keeping Track of Event Calls

Question

I have a main thread and another worker thread that performs some processing. I am currently signalling events from the main thread that the worker thread should respond to. In my main thread, I have the following:

frameNo = 1;
for (int j = 0; j < 10; j++) {
    frameNo++;
    tEvent->SetEvent();
}

In my worker thread, I have this:

int RThread::Run()
{   
    while (1) {
        WaitForSingleObject(myEvent->m_hObject, INFINITE);
        std::cout << "Event signalled!" << std::endl;
        std::cout << "Frame number is: " + std::string(obj->frameNo) << std::endl;
    }

    return 0;
}

As of right now, the worker thread only prints that frameNo is equal to 11, I'm assuming because the main thread is iterating so quickly that the worker thread only reaches that stage when frameNo is already incremented to 11. As a result, it's missing the numbers 1-10.

I don't want to miss the numbers 1-10 though, even though it may be a bit behind.

How can I somehow keep track of how many times the event is set? I was thinking of just not using events at all and, instead, just using a Queue to push variables to while the worker thread just takes from the queue. But if I use that queue, would I need some sort of critical section around the queue since both threads are modifying it?

Answer 1

If you want to ensure that the child thread sees each frame individually, you'll have to add synchronization to assure strict alteration between the parent and child threads.

For example, you could do something like:

Parent

1. generate frame
2. Signal child frame is ready
3. wait for signal from child that frame has been processed
4. repeat

Child

1. Wait for signal from parent
2. Process frame
3. Signal parent that frame has been processed
4. repeat

However, unless you're dead set on using threads, this seems to be a poor use of threads. The main point of threads is to run things concurrently, but in this case you seem to want serial execution, so you might as well use a single thread.

Yes, you could also just queue data up for the child thread to process. Yes, that typically involves a mutex. But if you're doing multi-threaded programming, a thread-safe queue is a good thing to have around anyway. For one example: https://stackoverflow.com/a/2375370/179910

Answer 2

Use std::promise and std::future to synchronize your thread ping pong actions. Just because you are using 28 year old MFC, doesn't mean you can't use modern C++ idioms. This capability has been around since C++11 and takes the sweat out of thread synchronization. C++11 shared smart pointers like std::shared_ptr and std::unique_ptr gave us leak-less dynamic memory management, and so on. Remember, C++ turns 40 soon and there are no signs yet its evolution is waning, fx, C++20 will bring us Concepts , Coroutines and Modules . This year Herb Sutter, chairman of the ISO C++, reported that over 200 academic wonks submitted papers last year, up from 125 the year before. And MFC can be the beneficiary if you are willing to learn something new (or your manager will let you).