Feal87's Blog

Just another programming weblog.

Data Synchronization between Tasks

Posted by feal87 on November 4, 2009

Little preface, the exam has gone very well (30/30), but I had some little “problems” these months that kept me from posting on this blog. 😛

Now let’s go to the topic at hand. One of the most important things I’ve done when working on making my engine multithreaded was defining a way to let multiple threads synchronize their data efficiently and thread-safely. Be sure to have read the previous post on the multithread engine before starting here.

Before starting discussing the possible ways to work out this problem let’s ask ourself

“Why should tasks have data in common?”

Well, in the common scenario of a game we have an AI task, an update task and a physics task (excluding the obvious draw, audio, etc…). Each of these three task should give their results to each another. In this particular case the AI task gives data to the physics task that gives data to the update task.

There are several ways to achieve this. The most commons are these two :

1) Using synchronizations constructs to be sure that only one thread is accessing the resource that is updated.
2) Synchronizing the data at the end of the frame on the engine thread.

We skip althogether the first way cause its really inefficient due to continous synchronizations and have lots of other issues and go right at the second way by taking a look at an image explaining how it work :

Frame Synchronization

As you can see the idea is to make the threads work together, and update their data at the end of the frame. This way they do not need to wait for each other to finish and can use all the resources they want. This way with an accurate task division you can maximize the use of resources without creating over-complex structures.

Please remember that if the chain of waiting is very long you can have some slowdown between action and reaction in the game. In this example we have a chain of 3 threads, considering them synched at 60 FPS we have 3/60 (48 milliseconds) of second of wait before an action in the update cause a reaction in the draw.

How can we actually create this in an application?

Let’s see a scrap of how my old implementation was done. (i’m currently working at improving the implementation to be more extensible and fast, but the foundation concepts are the same so it doesn’t matter for us :))

Synchronization Manager

Synchronization Types

My solution works by having a Synchronization Manager for each engine.

A Synchronization Manager is an entity that manages what we can call a “Event List”, a list of events that NEEDS to be synchronized (like the reaction of a ball to the wind in a physics system) and actually do the synchronization at the end of the frame in each engine.

If some task need to share some resource it creates an event and get an ID that identify that event, the task can update the resource using the appropriate method of the Synchronization Manager.

The other tasks can subscribe to that event and receive at the end of each frame any modify that occurred on that resource (if any).

Simple isn’t it? 😉

I hope this reading has been useful to you,
That’s all from me for today,
See you soon with another article. 😉 

P.S. I think I’ll work out a detailed article on the Content Managing big rehaul I’ve done for my engine some weeks ago. I think it will be an interesting reading for all of you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: