multi-thread 처리의 문제

풀 스크린의 Microsoft® Direct3D® 애플리케이션은, Direct3D 런타임에 윈도우 핸들을 제공한다. 이 윈도우는 런타임에 의해 훅 된다. 이것은, 애플리케이션의 윈도우 메시지 프로시저에게 건네진 모든 메시지가, 우선, Direct3D 런타임 독자적인 메시지 처리 프로시저에 의해 조사할 수 있는 것을 의미한다.

디스플레이 모드의 변경은, 하위의 operating system에 짜넣어진 지원 루틴에 의해 영향을 받는다. 모드가 변경되면 시스템은 복수의 메시지를 모든 애플리케이션에 송신한다. Direct3D 애플리케이션은, 메시지는 윈도우 프로시저 thread로 수신한다. 이 thread는,IDirect3DDevice9::Reset 또는 IDirect3D9::CreateDevice (또는 디스플레이 모드를 변경하는 경우가 있는 IDirect3DDevice9 의 마지막 IUnknown::Release )를 호출한 thread와 반드시 같지 않다. Direct3D 런타임은, 복수의 크리티컬 섹션을 내부에서 보관 유지한다. 적어도 1 개의 크리티컬 섹션이,IDirect3DDevice9::Reset 또는 IDirect3D9::CreateDevice 에 의한 모드 변환의 뒤도 보관 유지되므로, 이러한 크리티컬 섹션은, 애플리케이션이 모드 변경에 관련하는 윈도우 메시지를 수신한 후도 보관 유지된다.

이 설계는, 은근히 multi-thread 애플리케이션을 의도하고 있다. 특히, 애플리케이션은 윈도우 메시지 처리 thread를 Direct3D thread로부터 완전하게 분리해야 한다. 1 개의 thread로 모드 변경을 실시하면서, 다른 thread로 Direct3D 의 호출을 실시하는 애플리케이션은, 데드 록의 위험성이 있다.

이러한 이유로부터, Direct3D 에서는,IDirect3DDevice9::Reset,IDirect3D9::CreateDevice,IDirect3DDevice9::TestCooperativeLevel , 또는 IDirect3DDevice9 의 마지막 Release 의 각 메서드는, 윈도우 메시지를 처리하는 thread와 같은 thread에서만 호출할 수 있도록 설계되고 있다.