Problemas de multithreading (Direct3D 9)

Os aplicativos Direct3D de tela inteira fornecem um identificador de janela para o tempo de execução do Direct3D. A janela é manipulada pelo tempo de execução. Isso significa que todas as mensagens passadas para o procedimento de mensagem da janela do aplicativo foram primeiro analisadas pelo procedimento próprio de tratamento de mensagens do tempo de execução do Direct3D.

As alterações no modo de exibição são afetadas pelas rotinas de suporte incorporadas no sistema operacional subjacente. Quando ocorrem alterações de modo, o sistema transmite várias mensagens para todas as aplicações. Em aplicativos Direct3D, as mensagens são recebidas no thread de procedimento da janela, que não é necessariamente o mesmo thread chamado IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice (ou a versão final do 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 destas seções críticas é mantida durante a mudança de modo causada por IDirect3DDevice9::Reset ou IDirect3D9::CreateDevice, estas seções críticas continuam a ser mantidas quando o aplicativo recebe mensagens de janela relacionadas à mudança de modo.

Esse design tem algumas implicações para aplicativos multithreaded. Em particular, uma aplicação deve assegurar-se de segregar fortemente os seus threads de manipulação de mensagens de janela dos 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 ser bloqueado.

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

Tópicos relacionados

Dicas de Programação