Multithreading-problemen (Direct3D 9)

Direct3D-toepassingen op volledig scherm bieden een venstergreep voor de Direct3D-runtime. Het venster is gekoppeld aan de runtime. Dit betekent dat alle berichten die aan de berichtprocedure van het venster van de toepassing zijn doorgegeven, eerst zijn onderzocht door de eigen berichtafhandelingsprocedure van Direct3D.

Wijzigingen in de weergavemodus worden beïnvloed door ondersteuningsroutines die zijn ingebouwd in het onderliggende besturingssysteem. Wanneer de modus verandert, verzendt het systeem verschillende berichten naar alle toepassingen. In Direct3D-toepassingen worden de berichten ontvangen op de thread voor de vensterprocedure. Dit is niet noodzakelijkerwijs dezelfde thread die IDirect3DDevice9::Reset of IDirect3D9::CreateDevice heeft aangeroepen (of de uiteindelijke vrijgave van IDirect3DDevice9, wat kan leiden tot een verandering van de weergavemodus). De Direct3D-runtime onderhoudt intern verschillende kritieke secties. Omdat ten minste één van deze kritieke secties wordt vastgehouden tijdens de modusschakeling die wordt veroorzaakt door IDirect3DDevice9::Reset of IDirect3D9::CreateDevice, worden deze kritieke secties nog steeds vastgehouden wanneer de toepassing de gerelateerde vensterberichten voor moduswijziging ontvangt.

Dit ontwerp heeft enkele gevolgen voor multithreaded-toepassingen. Een toepassing moet er met name voor zorgen dat de threads voor het verwerken van vensterberichten sterk worden gescheiden van de Direct3D-threads. Een toepassing die een moduswijziging op één thread veroorzaakt, maar Direct3D-aanroepen uitvoert op een andere thread in de vensterprocedure, loopt gevaar voor impasses.

Om deze redenen, Direct3D is zo ontworpen dat de methoden IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel, of de definitieve release van IDirect3DDevice9 alleen kunnen worden aangeroepen vanuit dezelfde thread die vensterberichten verwerkt.

Verwante onderwerpen

Programmeertips