CODEWITHSUNDEEP
c++multithreadingc++11
mfaieghi
mfaieghi

Reputation: 610

How to maintain certain frame rate in different threads

I have two different computational tasks that have to execute at certain frequencies. One has to be performed every 1ms and the other every 13.3ms. The tasks share some data.

I am having a hard time how to schedule these tasks and how to share data between them. One way that I thought might work is to create two threads, one for each task.

The first task is relatively simpler and can be handled in 1ms itself. But, when the second task (that is relatively more time-consuming) is going to launch, it will make a copy of the data that was just used by task 1, and continue to work on them.

Do you think this would work? How can it be done in c++?

Upvotes: 1

Views: 1065

Answers (3)

Maxim Egorushkin
Maxim Egorushkin

Reputation: 136208

There are multiple ways to do that in C++.

One simple way is to have 2 threads, as you described. Each thread does its action and then sleeps till the next period start. A working example:

#include <functional>
#include <iostream>
#include <chrono>
#include <thread>
#include <atomic>
#include <mutex>

std::mutex mutex;
std::atomic<bool> stop = {false};
unsigned last_result = 0; // Whatever thread_1ms produces.

void thread_1ms_action() {
    // Do the work.

    // Update the last result.
    {
        std::unique_lock<std::mutex> lock(mutex);
        ++last_result;
    }
}

void thread_1333us_action() {
    // Copy thread_1ms result.
    unsigned last_result_copy;
    {
        std::unique_lock<std::mutex> lock(mutex);
        last_result_copy = last_result;
    }

    // Do the work.
    std::cout << last_result_copy << '\n';
}

void periodic_action_thread(std::chrono::microseconds period, std::function<void()> const& action) {
    auto const start = std::chrono::steady_clock::now();
    while(!stop.load(std::memory_order_relaxed)) {
        // Do the work.
        action();

        // Wait till the next period start.
        auto now = std::chrono::steady_clock::now();
        auto iterations = (now - start) / period;
        auto next_start = start + (iterations + 1) * period;
        std::this_thread::sleep_until(next_start);
    }
}

int main() {
    std::thread a(periodic_action_thread, std::chrono::milliseconds(1), thread_1ms_action);
    std::thread b(periodic_action_thread, std::chrono::microseconds(13333), thread_1333us_action);

    std::this_thread::sleep_for(std::chrono::seconds(1));
    stop = true;
    a.join();
    b.join();
}

If executing an action takes longer than one period to execute, then it sleeps till the next period start (skips one or more periods). I.e. each Nth action happens exactly at start_time + N * period, so that there is no time drift regardless of how long it takes to perform the action.

All access to the shared data is protected by the mutex.

Upvotes: 3

Timmy_A
Timmy_A

Reputation: 1232

You can use C++ threads and thread facilities like class thread and timer classes like steady_clock like it has been described in previous answer but if this solution works strongly depends on the platform your code is running on.

1ms and 13.3ms are pretty short time intervals and if your code is running on non-real time OS like Windows or non-RTOS Linux, there is no guarantee that OS scheduler will wake up your threads at exact times.

C++ 11 has the class high_resolution_clock that should use high resolution timer if your platform supports one but it still depends on the implementation of this class. And the bigger problem than the timer is using C++ wait functions. Neither C++ sleep_until nor sleep_for guarantees that they will wake up your thread at specified times. Here is the quote from C++ documentation.

sleep_for - blocks the execution of the current thread for at least the specified sleep_duration. sleep_for

Fortunately, most OS have some special facilities like Windows Multimedia Timers you can use if your threads are not woken up at expected times.

Here are more details. Precise thread sleep needed. Max 1ms error

Upvotes: 1

Gem Taylor
Gem Taylor

Reputation: 5613

So I'm thinking that task1 needs to make the copy, because it knows when it is safe to do so. Here is one simplistic model:

Shared:
    atomic<Result*> latestResult = {0};

Task1:
    Perform calculation
    Result* pNewResult = new ResultBuffer
    Copy result to pNewResult
    latestResult.swap(pNewResult)
    if (pNewResult)
        delete pNewResult; // Task2 didn't take it!

Task2:
    Result* pNewResult;
    latestResult.swap(pNewResult);
    process result
    delete pNewResult;

In this model task1 and task2 only ever naggle when swapping a simple atomic pointer, which is quite painless.

Note that this makes many assumptions about your calculation. Could your task1 usefully calculate the result straight into the buffer, for example? Also note that at the start Task2 may find the pointer is still null.

Also it inefficiently new()s the buffers. You need 3 buffers to ensure there is never any significant naggling between the tasks, but you could just manage three buffer pointers under mutexes, such that Task 1 will have a set of data ready, and be writing another set of data, while task 2 is reading from a third set.

Note that even if you have task 2 copy the buffer, Task 1 still needs 2 buffers to avoid stalls.

Upvotes: 1

Related Questions