Hi,

I have a few issues I'm trying to get my head around.

I'm trying to build a game where I dont drop frames at 60fps - especially during gameplay and as much as possible during menus, front end etc.

File access: I have a "file system thread" - most file operations, including content load happen on that thread.

Question: Is this a good practice? I was fairly happy with that approach and was convinced it was giving good results but more recently have seen quite a few spikes where they shouldnt be any and they coincide with my file access patterns on that thread.

Netwrok access: I run an online hiscore boards system that synchronises wiht other users behind the scenes - runs on yet another thread.

Question: Does networking benefit from being on a thread? I'm getting quite nasty stalls every time I create a hosting session or players join...

Audio threading: Is there any benefit in moving the xact audio engine update to another thread?

Finally, I'm aware that the first thing to look at is the GC and patterns of allocation. That has detiriorated recently but is in general is fairly clean - for example I dont allocate/free anything during gameplay. I use the CLI profiler etc... I'm just checking if there are any other gotchas with the issues above.

Thank you,
anx

Moving file IO to a separate thread can be a big win.

Moving networking to a separate thread can be a win, but not usually big.

The audio engine is internally multithreaded, so you won't gain much if anything from doing this yourself.

The biggest issue with threading is that the XNA Framework uses fairly coarse locks to protect itself against reentrancy: it basically has one critical section per area of functionality (graphics, sound, networking, etc). So if you have a background thread in the middle of some slow operation that takes out a lock (eg. SetData on a large texture), and the foreground thread attempts to use that same area of the framework at the same time, the two threads become serialized. So if you move networking to a thread, you want to move all networking: it's not a great idea to eg. call NetworkSession.Update on a worker thread, but then have the main thread sending packets at the same time (this will work fine, you just won't get any actual parallelism).

Audio and networking already work on their own threads. You need to use a profiler to see where your spikes are coming from. It's possible the spikes are caused by a bunch of garbage collection or something.

I've actually found it to be worthwhile to move audio to another thread, but my game may be unusual in that it has a large number of active sounds and makes heavy use of positional audio. I was losing around 3-6% of my main thread CPU time calling into the XACT APIs (it looks like each call involves a managed->native transition and some floating point arithmetic), and in some cases I was seeing my framerate tank when first preparing a Cue to play. Moving all that stuff (Apply3D in particular) off onto another thread solved that problem for me.

It's definitely true that XACT seems to do most of its work on a thread of its own, though - I just wish it did *all* of its work there so I wouldn't have to hassle with a queue and synchronization to do all my Apply3D/Play/Stop on a worker thread :)

Doing file I/O and network operations on another thread both seem like good ideas to me, if only because both types of operations can potentially block for any amount of time. You won't necessarily get improved performance or eliminate stalls, but it'll at least avoid situations where your game freezes for a long period of time.

File IO, definitely. But in XNA, the networking API is already threaded.

mpipe:

File IO, definitely. But in XNA, the networking API is already threaded.

While it is true that the networking API makes use of another thread, there's plenty of code inside the various networking APIs that runs on the current thread and acquires locks, so I wouldn't assume that it's not going to block the main thread, especially if the OP is trying to eliminate pauses. But it's definitely less likely to be an issue than file IO.