Problèmes de multithreading (Direct3D 9)
Les applications Direct3D plein écran fournissent un handle de fenêtre au moment de l’exécution de Direct3D. La fenêtre est accrochée par l’exécution. Cela signifie que tous les messages passés à la procédure de message de fenêtre de l’application ont d’abord été examinés par la propre procédure de gestion des messages de l’exécution de Direct3D.
Les modifications du mode d’affichage sont affectées par les routines de prise en charge intégrées au système d’exploitation sous-jacent. Lorsque des changements de mode se produisent, le système diffuse plusieurs messages à toutes les applications. Dans les applications Direct3D, les messages sont reçus sur le thread de procédure de fenêtre, qui n’est pas nécessairement le même thread que celui appelé IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice (ou la version finale de IDirect3DDevice9, ce qui peut entraîner une modification du mode d’affichage). L’exécution de Direct3D gère plusieurs sections critiques en interne. Étant donné qu’au moins une de ces sections critiques est conservée sur le commutateur de mode provoqué par IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice, ces sections critiques sont toujours conservées lorsque l’application reçoit les messages de fenêtre liés au changement de mode.
Cette conception a certaines implications pour les applications multithread. En particulier, une application doit s’assurer de séparer fortement ses threads de gestion des messages de fenêtre de ses threads Direct3D. Une application qui provoque un changement de mode sur un thread, mais effectue des appels Direct3D sur un thread différent dans sa procédure de fenêtre est en danger d’interblocage.
Pour ces raisons, Direct3D est conçu de sorte que les méthodes IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel ou la version finale de IDirect3DDevice9 puissent uniquement être appelées à partir du même thread qui gère les messages de fenêtre.
Rubriques connexes