CODEWITHSUNDEEP
c++multithreadingsynchronization
James Mitchell
James Mitchell

Reputation: 315

Synchronizing looping threads

I am making some multi-threaded video game code. Before I began coding I looked at an article describing vaguely Valve's solution to multi-threaded game design. A key concept I gleaned from the article is thread synchronization. I don't know if this is how Valve does it but I imagined multiple threads each executing a game loop. At the end of each iteration, the threads pause and wait for other threads to finish their current iteration, then synchronize shared data. I figure that besides the overhead is this management scheme, there would be no different to just let the threads operate completely asynchronously. The article mentioned a thread used exclusively for syncing but I am trying to get a different solution to work correctly. This is how I (try) to do it:

        // at end of loop on each thread...
        sig_thread_done();

        while (!is_sync_done())
        {
            PauseExecution(1);
        }

sig_thread_done and is_sync_done are function objects from another class that controls a list of all "threads". These functions look like this:

bool Core::IsFrameDone()
{
    MutexLock lock(manager_mutex);

    if (waiting_components == -1)
    {
        waiting_components = 0;
        return true;
    }
    return false;
}

void Core::SignalFrameDone()
{
    MutexLock lock(manager_mutex);

    if (++waiting_components == (int)components.size()) // components == threads
    {
        //sync shared data...
        waiting_components = -1; // -1 signifies that all threads have completed their iteration
    }
}

The problem is that a fast thread can exit its waiting loop and come back around to it again before other threads have a chance to exit there's. So the other threads miss the exit through is_sync_done returning false before another thread begins waiting and the whole system gets stuck waiting forever.

I can't find an easy way to resolve this issue. I really like this approach because synchronization doesn't get stalled while some independent thread performs the sync.

I appreciate any insight or suggestions anyone has to offer.

Link to article.

Upvotes: 0

Views: 1482

Answers (2)

Necrolis
Necrolis

Reputation: 26181

For something like this you want to sync on a barrier, with something like a Win32 Event (or an array thereof), this makes sure you cannot get the situation you described (the barrier ensures that everything syncs up to the same frame) while at the same time freeing CPU time, as waiting on events is done as a kernel signal, and sleeps the thread till that signal is received. You'd also what to use wait-free algorithms in there, these work particularly well if you have a job/task based threading model, where certain things can be decoupled from the system.

Also, here is a better publication on multi-threading the source engine, its far more in depth and technical (they also specifically state that they avoid mutexes for this sort of thing).

Upvotes: 0

OSH
OSH

Reputation: 2937

I think you are trying to re-invent a Thread barrier.

Upvotes: 1

Related Questions