So I've been toying with this idea for some time now, but my limited experience with multithreading is making me wonder how plausible my ideas really are~

Have a look at ContentTracker (in my sig). I'm think it handles both of your stated goals, but regardless it should be helpful to see the inner workings of a custom ContentManager.

It supports Async loading by loading sequentially on a separate thread. The items to be loaded are queued up and yes, it calls a delegate on the main thread once an object has been loaded. This is probably the best approach when implementing a streaming content situation.

It includes a small example game implementing the streaming content. To minimize download size, I made all the content tiny, but when you start loading large models / textures, you may notice an issue I stumbled against: When the graphics device resources (vertex & index buffers) are instantiated, it blocks the main thread. I haven't figured out a way around this yet, other than to ensure all of the content is broken into relatively small bits and possibly to stagger the calls to load them (not nice). It may not be a problem for you though... even in Unreal Tournament 3, the start of the levels always seemed to stutter a bit as it streamed in the last of the content (well that's what I assumed it was doing anyway).

Your post doesn't show your sig right now- have you maybe disabled it recently and forgotten to show it again?

That's weird, I see his sig just fine.  Here's the link: http://contenttracker.codeplex.com/

Also with regards to the "blocking the main thread" issue...typically what games will do is they do all of the I/O and conversion stuff on a worker thread, then hand off the final processed data to the main thread.  The main thread then does the final task of creating the graphics resource and filling it with the data.  It doesn't totally solve the problem since you still have to do it on the main thread, but at least it lets you do it at a time that's convenient...and also when you're not in a lost device state.  Unfortunately since the ContentTypeReaders for things like Texture2D, Effect, and Model aren't set up to do this so you'd have to make your own version along with new intermediate types.

Ah- I can see signatures now- but thank you for the link anyways MJP^^

Make sure you acquire a lock while loading resources, and acquire that same lock when your graphics device is reset. You can do this by attaching event handlers to GraphicsDeviceManager.DeviceReset and GraphicsDeviceManager.DeviceResetting. Acquire the lock (using Monitor.Enter) in DeviceResetting and release it (using Monitor.Exit) in DeviceReset. Acquire the same lock (you can use a lock () block for this probably) before loading textures or other device resources. If you don't do this you'll get intermittent failures.

Also, you should be aware that it's currently close to impossible to do much content streaming in an XNA game - between the tremendous amount of garbage generated by the Texture2D loader, and the apparently unavoidable pauses when creating resources, your game will stutter a lot. (There may be some ways around this, though, if you're dead-set on streaming.)

Monitor.Enter and Monitor.Exit are not available on the Xbox, unfortunately.
On the other hand, the device does not generally get reset on the Xbox, after you've started your game.

Monitor.Enter and Exit are available on Xbox.

The C# lock statement translates into Monitor.Enter and Exit calls, so the C# language itself would be broken if these were not available!

jwatte:

Monitor.Enter and Monitor.Exit are not available on the Xbox, unfortunately.
On the other hand, the device does not generally get reset on the Xbox, after you've started your game.

You're probably thinking of Monitor.Wait/Monitor.Pulse.

You're correct about device resets - the only case I know of where a reset triggers on the 360 is if you call GraphicsDeviceManager.ApplyChanges.

Yes, I was thinking of Pulse/Wait. Sorry to confuse the issue.

So does that mean on the XBox, you wouldn't have to worry about handing lost/reset devices and such if you're never going to call GraphicsDevice.Apply() then?

Looking more deeply into this subject, I have things mostly working how I intend, but to have some things more efficient on some other cross-thread code, I have a question:

Nyxojaele:

Looking more deeply into this subject, I have things mostly working how I intend, but to have some things more efficient on some other cross-thread code, I have a question:

I know it's not thread-safe to have situations where an object can be modified in one thread while at the same time being read in another thread, but if you can GUARANTEE that the object will not be modified, is it considered safe to read the same object from multiple threads at the same time?

Yes.

Note that you need to make sure that the data structure you're using doesn't cause modifications when read. This is true of most data structures, but not all - for example, you wouldn't want to read from a 'least recently used' or 'most recently used' data structure from multiple threads at the same time.