Problemas de multithreading (Direct3D 9)
Las aplicaciones direct3D de pantalla completa proporcionan un identificador de ventana al tiempo de ejecución de Direct3D. La ventana está enlazada por el tiempo de ejecución. Esto significa que todos los mensajes pasados al procedimiento de mensaje de ventana de la aplicación han sido examinados primero por el propio procedimiento de control de mensajes del tiempo de ejecución de Direct3D.
Los cambios en el modo de presentación se ven afectados por las rutinas de soporte integradas en el sistema operativo subyacente. Cuando se producen cambios en el modo, el sistema difunde varios mensajes a todas las aplicaciones. En las aplicaciones de Direct3D, los mensajes se reciben en el subproceso de procedimiento de ventana, que no es necesariamente el mismo subproceso que llamó A IDirect3D9::Reset o IDirect3D9::CreateDevice (o la versión final de IDirect3DDevice9, que puede provocar un cambio de modo de presentación). El tiempo de ejecución de Direct3D mantiene internamente varias secciones críticas. Dado que al menos una de estas secciones críticas se mantiene en el modificador de modo causado por IDirect3DDevice9::Reset o IDirect3D9::CreateDevice, estas secciones críticas todavía se conservan cuando la aplicación recibe los mensajes de ventana relacionados con el cambio de modo.
Este diseño tiene algunas implicaciones para las aplicaciones multiproceso. En concreto, una aplicación debe asegurarse de separar fuertemente sus subprocesos de control de mensajes de ventana de sus subprocesos de Direct3D. Una aplicación que provoca un cambio de modo en un subproceso, pero realiza llamadas de Direct3D en un subproceso diferente en su procedimiento de ventana está en peligro de interbloqueo.
Por estos motivos, Direct3D está diseñado para que los métodos IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel o la versión final de IDirect3DDevice9 solo se pueda llamar desde el mismo subproceso que controla los mensajes de la ventana.
Temas relacionados