Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

We are building a multithreaded game engine and we've encountered some problems as described below.

The engine have 3 threads in total: script, render, and audio. Each frame, we update these 3 threads simultaneously. As these threads updating themselves, they produce some tasks and put them into a public storage area. As all the threads finish their update, each thread go and copy the tasks for themselves one by one. After all the threads finish their task copying, we make the threads process those tasks and update these threads simultaneously as described before. So this is the general idea of the task schedule part of our engine.

Ok, well, all the task schedule part work well, but here's the problem:

For the simplest, I'll take Camera as an example:

local oldPos = camera:getPosition()  -- ( 0, 0, 0 )
camera:setPosition( 1, 1, 1 )        -- Won't work now, cuz the render thread will process the task at the beginning of the next frame
local newPos = camera:getPosition()  -- Still ( 0, 0, 0 )

So that's the problem: If you intend to change a property of an object in another thread, you have to wait until that thread process this property-changing message. As a result, what you get from the object is still the information in the last frame.

So, is there a way to solve this problem? Or are we build the task schedule part in a wrong way? Thanks for your answers :)

share|improve this question
    
I know it's ok that we store those properties and states at the C++ side, but you know that is a HUGE amount of work. I'm looking for some solution that is easier to do. –  Peter Ren Jun 5 '12 at 8:10

3 Answers 3

up vote 1 down vote accepted

If objects are in separate threads and you're treating threads as completely separate processes, the objects must obey one of 2 restrictions:

  1. The objects in Thread 1 can work with old data for the objects in Thread 2 (so it doesn't matter that the changed position is 1 frame out of date)
  2. The objects in Thread 1 don't care at all about the objects in Thread 2.

Generally speaking, you have a mix of both. You shouldn't be changing things in another thread and expecting to operate on the result instantly - instead, you should just operate on the data you have currently, which will have changed next time.

If you really need to be able to tell an object in another thread to update, and then need to perform actions dependent on those changes, then you need to make the dependent actions a new task that is dependent on the update task. Your task scheduler should be able to make 1 task wait until another has completed before proceeding.

share|improve this answer
    
This really helps, thank you :) –  Peter Ren Jun 6 '12 at 1:41

You can use double or triple buffering for that case, meaning you store data twice, scripting part works with one series of it and rendering part works with the other. At the end of each frame render thread will copy all those data for next frame use into it's buffer.

share|improve this answer

I think the way you design your engine is wrong. The camera is an object and you want to change its data. Changing data is not a task.

I think you must use mutex for changing the camera object data. With mutex you can be sure when one thread changes the camera data other threads can't change any data of camera. But I don't know what will happen if you change the camera position in middle of the rendering maybe some objects render with new camera position and some with previous one maybe the renderer must get a copy of camera object before starting to render the scene and use it until the end of the frame.

share|improve this answer
    
I know that changing data is not a task, I just wanna make it simple enough. What I mean is, when you perform a task that may change some state of an object in the other thread, how can I get the result state correctly in the script thread? –  Peter Ren Jun 6 '12 at 1:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.