Synchronizing looping threads

Question

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.

Conceptually, you try to implement a barrier - so why not use a tested implementation instead, e.g. `pthread_barrier`? — Alexey Kukanov, Jan 22 '12 at 07:48

score 1 · Answer 1 · answered Jan 22 '12 at 07:50

1

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

answered Jan 22 '12 at 07:50

OSH

2,847
3
25
46

That seems to be what everyone else is saying. I've never heard of a thread barrier before, I suppose I should have done more reading before doing I started this project. Thanks for the comment. – James Mitchell Jan 22 '12 at 23:21
Much thanks, dude, never knew about that synchronization primitive! – Tims Oct 03 '22 at 13:06

score 0 · Answer 2 · answered Jan 22 '12 at 07:51

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).

Thanks. Before I tried this I had all threads run asynchronously and used mutexes where necessary. This will eliminate the overhead of all that sporadic syncing. — James Mitchell, Jan 23 '12 at 03:33

Synchronizing looping threads

2 Answers2

Linked