Timers: Thread-suspending?

[blazko]

Hello,

A firend and me are developing a game where some subsystems run in dedicated threads:

- Display + Input (has to)
- Base stuff and resource management
- AI
- physics
- sound

Now, we plan that each thread will suspend itself for a defined amount of time (configurable). This way we can spend some susbsystems more or less CPU time.
My two questions are:
- are there any advantages (fyi: we want same technique for every thread, so Display.sync() is not a favourite and does only apply to the dusplay thread ;-)
- what e.g. about sound subsystem? we use OpenAL but will pausing the thread also cause sound stutter or just cuase pausing of our sound subsystem management code (as intended). I do not know if sound is always untouched cos it is handled in hardware and thus not even within the same application

doh, expressed myself too complicated but hope you got my point ;-)

Thanks and regards,
Timo

p.s. pausing will be scalar as we use System.nanoTime difference as factor to guarantee same timing on different systems

[Matzon]

You cannot pause sound threads. Audio is constantly streamed and if it underflows you will hear garbage.

Generally using multiple threads increases the complexity considerably, so unless you have very good reasons I would stall on it.

System.nanoTime has issues with multithreading and powersaving stuff, so I would be vary of using it (at least on windows).

[wolf_m]

If you're just using threads to control allocation of CPU time, you don't need threads at all. You just need some control class, a time manager that calls methods at instances at specific times. Normally, you'd do that in your 'while(running)' loop.

If you use threads, the threaded instructions will run parallelly. It's very difficult to always have distinct states that way. You will run into race conditions for sure.

But if you somehow get threads working with always distinct states, you could of course make AI, physics and sound run in separate threads. Display and input: Don't do it. Don't interrupt the sound thread. Don't make multiple threads for the sound. Just interact with the sound system by allocating buffers, buffering, starting and stopping playback. Don't stop it by suspending its thread, won't work.

[blazko]

Hello,

Thanks for your replies!

@Matzon
That is new to me. Until now, I kept all within a single loop but always paused the application for some time to guarantee same runtimes. I think I am getting something wrong ;-) I thought than one always does some sleep code within the main loop...
I read on some game development site, that threading increases development time by min. factor 2 - but that is okay ;-)
So, better stick to LWJGL timer instead? I read that when defining Java5 as minimum, nanTime would be the choice.

@wolf_m
We plan at least to put physics and animation into seperate threads as this will benefit from multicore CPUs as they become more and more common. When our project is finished I think anyone has multicore CPUs ;-)
I read in an interview with one of the Unreal3 developers that especially dedicating physics and animation to own threads greatly improved speed on such systems.
Also AI: i think that not everything is to be calculated per frame. Other hacks would be to execute some code only all n frames but I think this is not so elegantly. Having multiple threads with all different timing is more intutivie for me ;-)
Sound: only the "sound manager" is to be run into a different threads, not all single ones. I think that we will end up having max 4-5 threads as more will be counter-productive during runtime (management overhead).

Last but not least I think that we can avoid sync problems such as race conditions and deadlocks by just letting code in own threads that do not depend strictly on each other. Additionally, I thin avoidung sync blocks may be some kind of advantage as we do not that accuracy than other critical apps need (I am developing multithreaded apps that are not games and know that there other things count).
;-)

I am very interested in your comments (means, if you can dig thru my weird posting) ;-)

Agai, very big thanks for your replies!

Regads,
Timo

P.S.: I have NO practical experience w/ OpenAL and am just trying to leanr it - just did OpenGL for some years w/ interrupt

[wolf_m]

I've implemented streaming oggs in a separate thread via OpenAL with some help (see the Tetrismus thread). This seems to be a pretty reliable technique.

After all, OpenAL manages its playback with a separate thread itself. But once you begin spawning thread after thread for multiple sound playback, you will run into OpenAL errors.

I think trying to improve performance for multicore CPUs is a good idea, and of course the best way is to use threads.

Considering physics and AI: That's what I meant with distinct states. No matter when stuff is displayed, you just need a clear state that doesn't blend over to the next / previous state or with temporary states and that won't change as long as you read from it. This has to be a central part of your concept. There are different ways to achieve this.
And the latest distinct state that's taken into consideration for the whole game logic has to be near the displayed state considering the time diff. You could of course just skip states if you're getting out of synch as long as the result is near-accurate and believable.

Normally, I say: First make it work, then make it right. In this case, I'd say: First do the concept, then do the coding, then fix the code to make it work.

Edit: One more thing: Suspending threads can lead to quite strange results considering OpenGL and input recognition. I had such a bug when suspending after reading input - it was read again and again after going back. And this is just one example. Always use timers over suspended threads, that's what I think.

But with AI and physics, it's another deal - depends totally on the implementation.

[Fool Running]

All I have to say is "good luck" :lol: . I've done some multithreading with only 2 threads and have found it to more than double dev time for that part of the code (not for initial coding, but for bug finding/fixing). Multithreaded apps are insanely hard to debug when they deadlock/race. Especially when all you get back from a tester is a stack for one of the threads, or them saying "it just stoped working" :wink:

Of course, that experience was in C# (Explains a lot of things :roll: ), but still... Good luck :lol:

[blazko]

Rehi again,

just wanted to warm up this thread ;-)
Now, in Java 1.6/6 there is a new implementation of the sleep() method (now with nano precision?). Can this be recommended or are yet other implementations better - given that we define Java 6 as minimum requirement?

Otherwise, I still have problems to understand how Timers work (and how to use them in multi-threaded environments). Problem w/ sleep (besides what you mentioned above) from my point of view is that even if sleep() works precise, I would not have same timing because I do not know how long calculations require for the current thread per iteration before sleep is invoked.
How do timers work? Do they have a dedicated thread and have a simple loop with a precise sleep and because they have same calculation efforts per iteration they always scale the same?

Thanks for some thoughts! ;-)

Regards,
Timo

[ThorPrime]

I would really recommend not sleeping your main thread to ensure equal play rates (I assume you are doing this so fast machines don't seem to be playing at lighting speeds.) Instead, just scale all your values by how long it took to go though the game loop, and run it as fast as you can. I am using a similar design on my game where we have threads for rendering, input, networking, and sound, and server has separate threads for AI, networking, and main processing. Non of the threads are slept and the OS does a pretty good job of making sure each thread gets enough CPU time to do what it needs to do. Manually doing thread management is on the whole, a bad idea.