Problemi di multithreading (Direct3D 9)
Le applicazioni Direct3D a schermo intero forniscono un handle di finestra al runtime Direct3D. La finestra è agganciata dal runtime. Ciò significa che tutti i messaggi passati alla procedura di messaggio della finestra dell'applicazione sono stati esaminati per la prima volta dalla procedura di gestione dei messaggi di Direct3D.
Le modifiche alla modalità di visualizzazione sono influenzate dalle routine di supporto integrate nel sistema operativo sottostante. Quando si verificano modifiche alla modalità, il sistema trasmette diversi messaggi a tutte le applicazioni. Nelle applicazioni Direct3D i messaggi vengono ricevuti nel thread della routine della finestra, che non è necessariamente lo stesso thread che ha chiamato IDirect3DDevice9::Reset o IDirect3D9::CreateDevice (o la versione finale di IDirect3DDevice9, che può causare una modifica della modalità di visualizzazione). Il runtime Direct3D mantiene internamente diverse sezioni critiche. Poiché almeno una di queste sezioni critiche viene mantenuta durante il passaggio di modalità causato da IDirect3DDevice9::Reset o IDirect3D9::CreateDevice, queste sezioni critiche sono ancora tenute quando l'applicazione riceve i messaggi di finestra correlati al cambio di modalità.
Questa progettazione ha alcune implicazioni per le applicazioni multithreading. In particolare, un'applicazione deve essere sicura di separare fortemente i thread di gestione dei messaggi della finestra dai thread Direct3D. Un'applicazione che causa una modifica della modalità su un thread, ma esegue chiamate Direct3D su un thread diverso nella procedura della finestra è in pericolo di deadlock.
Per questi motivi, Direct3D è progettato in modo che i metodi IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevelo la versione finale di IDirect3DDevice9 può essere chiamato solo dallo stesso thread che gestisce i messaggi della finestra.
Argomenti correlati