次の方法で共有

マルチスレッドの問題 (Direct3D 9)

  • [アーティクル]

全画面表示の Direct3D アプリケーションは、Direct3D の実行時にウィンドウ ハンドルを提供します。 ウィンドウは実行時にフックされます。 つまり、アプリケーションのウィンドウ メッセージ プロシージャに渡されるすべてのメッセージは、最初に Direct3D ランタイムの独自のメッセージ処理プロシージャによって調べられます。

表示モードの変更は、基になるオペレーティング システムに組み込まれているサポート ルーチンの影響を受けます。 モードが変更されると、システムは複数のメッセージをすべてのアプリケーションにブロードキャストします。 Direct3D アプリケーションでは、メッセージはウィンドウ プロシージャ スレッドで受信されます。これは、IDirect3DDevice9::Reset または IDirect3D9::CreateDevice (または IDirect3DDevice9 の最終リリース) を呼び出したスレッドとは限りません。これにより、表示モードが変更される可能性があります。 Direct3D ランタイムでは、いくつかの重要なセクションが内部的に維持されます。 これらの重要なセクションの少なくとも 1 つは 、IDirect3DDevice9::Reset または IDirect3D9::CreateDevice によって発生するモード スイッチ全体に保持されるため、これらの重要なセクションは、アプリケーションがモード変更関連のウィンドウ メッセージを受信しても保持されます。

この設計は、マルチスレッド アプリケーションに影響を与える可能性があります。 特に、アプリケーションでは、ウィンドウ メッセージ処理スレッドを Direct3D スレッドから厳密に分離する必要があります。 1 つのスレッドでモードの変更を引き起こすが、ウィンドウ プロシージャ内の別のスレッドで Direct3D 呼び出しを行うアプリケーションは、デッドロックの危険にさらされています。

このような理由から、 Direct3D は、メソッド IDirect3DDevice9::Reset、 IDirect3D9::CreateDevice、 IDirect3DDevice9::TestCooperativeLevel、または IDirect3DDevice9 の最終リリースを、ウィンドウ メッセージを処理する同じスレッドからのみ呼び出すことができるように設計されています。

プログラミングのヒント