Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Ok, I have fairly little multi-threading experience, but i have done a similar thing before without issue...but this has me stumped.

This is in C++, Directx9 Visual Studio...

My game basically runs in one thread, apart from loading screens. When I want to load a new game, I fire up a new thread which goes through and does all of the simulation and asset loading stuff. Meanwhile, the original (base) thread displays an animated loading screen. Once the loading is finished, the loading thread sets a flag in tjhe loading screen saying it's done, and during the loading screens Draw() it spots the flag, ends the 'loading' thread, and starts the main game.

All of this works perfectly, in debug and release.

Except fullscreen...

For some reason, if I run the game in fullscreen mode, it goes wrong. The game hangs at the end of loading, and it looks like the flag in the loading screen is never getting set. if I force a debug break into the base thread, it seems to always be inside the D3D flip().

I can't see what I'm doing wrong. The loading thread does zero rendering. It creates some directx assets but never uses them. The flag I'm using to communicate between threads is a simple int, and it's read/write should thus be atomic. I've done a very similar thing in my previous games with no problems, but this has me stumped. Should I really be using CriticalSections etc for something this simple? Help!

share|improve this question
    
Log relevant data and actions on both threads, but be careful, logging can also change race conditions, but it will help you get a clearer picture for starters. Generally, use your debugger: code- and data-breakpoints and printf. –  Maik Semder Mar 8 '13 at 11:26

2 Answers 2

A quick google on the subject turned up this: Object Creation with Multithreading (Windows) It is for DX11 and not DX9, but the basic gist is that, DX is only under certain conditions thread safe.

DX behaves "radically" different in windowed and full screen modes. (In windowed mode DX sort of wait on WM_PAINT, but in full screen it renders away.) This probably unearths a race condition in your code and DX. My experience is, (though mostly with openGL,) that you want to interact with the graphic context only in the thread that created it.

My advice is that you implement the disk to memory operation in your worker thread and keep the actual upload to video mem in the main thread. (My code often has an implicit upload/free in the rendering subsystem.)

share|improve this answer

Flag variables that are accessed from multiple threads need to be declared as volatile, so the compiler doesn't optimize away the memory accesses and cache them in registers.

For something more complicated than a simple flag, more complex synchronization (e.g. a critical section) is generally required.

Also note that unless you use D3DCREATE_MULTITHREADED (which can badly affect performance) accessing the D3D device from multiple threads without using your own synchronization isn't safe.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.