Threading
Three quotes about threading in Ogre
Welcome to the new Ogre Wiki!
If you haven't done so already, be sure to visit the Wiki Portal to read about how the wiki works. Especially the Ogre Wiki Overview page.
If you haven't done so already, be sure to visit the Wiki Portal to read about how the wiki works. Especially the Ogre Wiki Overview page.
This is mainly just a rewording of this forum thread (year 2005) so go there for the full answer.
Sinbad wrote:
You should thread things that naturally fall into the background, ie to be spread over multiple frames. That's AI, buffering of streaming data, but probably not physics (because you need to keep it in sync with the frame rate if it's not going to look weird). None of these things are Ogre itself. Due to the fact that the graphics are the most noticeable thing, and that the GPU is asynchronous anyway, rendering processes are rarely farmed out to the background, so there's generally no need for thread safety. Projects which use threading thread non-graphical things.
The one case where it might be useful is background loading using the resource system. In Azathoth the resource system is (experimentally) thread safe if you set OGRE_THREAD_SUPPORT to 1, allowing you to load things in a background thread if you want. But that's only the resource system, nothing else is thread safe, and in my opinion has no need to be. We use boost::threads
for this, personally it seemed a much better solution than anything else I've seen (it reminds me of Java threads).
The one case where it might be useful is background loading using the resource system. In Azathoth the resource system is (experimentally) thread safe if you set OGRE_THREAD_SUPPORT to 1, allowing you to load things in a background thread if you want. But that's only the resource system, nothing else is thread safe, and in my opinion has no need to be. We use boost::threads
AlphaBeta wrote:
Keep in mind you don't need threads to run systems at varying rates (keep countdowns, if time is up step the system, if not move on).
If you're using ogre for a game threading isn't really necessary (like sinbad said, graphics are already asynchronous).
For things like physics, multi-steps are often done (instead of updating the physics simulation 30 milliseconds, you might have it do 15 milliseconds 2 times. Physics simulations get less accurate with bigger updates, which doesn't apply to most other systems).
You wouldn't want to simply run a physics update multiple times for each graphics one, you should work it out with timers and countdowns.
If you're using ogre for a game threading isn't really necessary (like sinbad said, graphics are already asynchronous).
For things like physics, multi-steps are often done (instead of updating the physics simulation 30 milliseconds, you might have it do 15 milliseconds 2 times. Physics simulations get less accurate with bigger updates, which doesn't apply to most other systems).
You wouldn't want to simply run a physics update multiple times for each graphics one, you should work it out with timers and countdowns.
QSilver wrote:
I should point out that even though Ogre is not thread-safe, there is no reason why your application cannot use threads. It just means that you cannot have multiple threads which deal with Ogre.
As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads.
As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads.
Contributors to this page: jacmoe
and
OgreWikiBot
.
Page last modified on Saturday 09 of January, 2010 04:28:08 GMT by jacmoe
.
The content on this page is licensed under the terms of the Creative Commons Attribution-ShareAlike License.
As an exception, any source code contributed within the content is released into the Public Domain.
Sidebar
Search box
Online users
45
online users

