Which is not what is being suggested here. If you are locking your vertex buffer to move objects then you are most likely doing it the wrong way.
threading is much better , i use it alot to lock index and vertex buffers and get smooth processing
Now items that would be good for a thread:
void GameApp::Update(float timeDelta)
//Get any new input
m_Physics->Update(timeDelta); //Delta clamped to 60 FPS inside physics
- Keyboard/mouse input
You could put updating objects and physics into a thread but synchronization would hurt and after the sync was done you would realize it was a linear process that didn't need threads. You must update physics before you update objects. You must get keyboard input and mouse input prior to updating anything. So you would end up waiting on events to fire off the update which means you are not gaining anything because you are not trying to do two things at once per se.
See a problem here? I do. Anytime the thread wakes up it will iterate through all objects. But if it doesn't get through all of the objects then some portion of them will still reflect the last frame's data and some will reflect the new frame's data. I don't think this is what you want to do. If you somehow force the thread to finish the loop (which you can't) then you are still doing everything linearily.
void ObjectMgr::Update(float timeDelta)
std::list<IGameObject *>::iterator iter(m_Objects.begin());
std::list<IGameObject *>::iterator end(m_Objects.end());
while (iter != end)
There would be a huge host of problems and sync issues to work out if you do it this way. I do know some games like Falcon 4: Allied Force makes use of threads for the AI but I think update is done in the main process. If not they figured out how to solve the above issues which is something I really wouldn't waste my time on unless your current FPS state dictates that you need it.
So if you have to do it this way be fully aware of the pitfalls you may encounter. Remember that using threads does not guarantee your application will perform any better.