Problemas de multithreading (Direct3D 9)

Aplicativos Direct3D de tela inteira fornecem um identificador de janela para o tempo de execução do Direct3D. A janela é conectada pelo tempo de execução. Isso significa que todas as mensagens passadas para o procedimento de mensagem de janela do aplicativo foram examinadas pela primeira vez pelo próprio procedimento de tratamento de mensagens do tempo de execução do Direct3D.

As alterações no modo de exibição são afetadas por rotinas de suporte internas no sistema operacional subjacente. Quando ocorrem alterações no modo, o sistema transmite várias mensagens para todos os aplicativos. Em aplicativos Direct3D, as mensagens são recebidas no thread de procedimento de janela, que não é necessariamente o mesmo thread chamado IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice (ou a versão final de IDirect3DDevice9, que pode causar uma alteração no modo de exibição). O tempo de execução do Direct3D mantém várias seções críticas internamente. Como pelo menos uma dessas seções críticas é mantida na opção de modo causada por IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice, essas seções críticas ainda são mantidas quando o aplicativo recebe as mensagens de janela relacionadas à alteração de modo.

Esse design tem algumas implicações para aplicativos multithread. Em particular, um aplicativo deve ter certeza de separar fortemente seus threads de tratamento de mensagens de janela de seus threads Direct3D. Um aplicativo que causa uma alteração de modo em um thread, mas faz chamadas direct3D em um thread diferente em seu procedimento de janela, corre o risco de deadlock.

Por esses motivos, o Direct3D foi projetado para que os métodos IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel ou a versão final de IDirect3DDevice9 só possam ser chamados do mesmo thread que manipula mensagens de janela.

Tópicos relacionados

Dicas de programação