スレッド化と Maya

Maya API スレッド化インタフェースの説明と例

このセクションでは、必要なスレッド化機能を説明することによって Maya API が提供する機能について説明し、Maya が提供するサンプル プラグインの一部の使用方法を紹介します。

Maya には、スレッドの作成、管理、ロックを支援する多数のスレッド化クラスがあります。これらのスレッド化クラスは、Intel の TBB スレッドに基づいて構築されており、内部処理に使用されます。また、ネイティブ スレッドに類似した API をプラグイン作成者に公開します。これらのクラスでは、プラグイン作成者が自分のプラグインで TBB を直接使用する必要はなく、TBB に精通する必要もありません。これらのスレッドは実際は Maya 内部スレッドであるため、適用されているスレッド数の設定が尊重され、プラグイン自体がスレッド化されたときに多数のアクティブ スレッドが作成される問題が回避されます。また、TBB によるスレッド化の実装方法が原因で発生する可能性のあるオーバーサブスクリプションの問題からも保護します。

API は以下の 3 つの主要な領域の機能を提供します。

• 分岐結合スレッド化実装モデル
• 非同期タスクベース スレッド化モデル
• スレッド化同期インタフェース

アーキテクチャはオブジェクト参照カウントを使用してメモリ管理を支援し、すべてのユーザが処理を完了するまでオブジェクトの割り当て解除を遅らせます。API 関数のコールが成功するとインタフェース ポインタが返され、コールする側は処理が完了したらそのインタフェースに対して release() をコールします。これを実行しないと、メモリ リークが発生する場合があります。

コールが常に成功すると思い込まず、返される MStatus は常に確認してください。

Maya API を使用したスレッドの作成と管理

Maya API を使用したロック操作

MAtomic::preIncrement()
MAtomic::postIncrement()
MAtomic::increment()
MAtomic::preDecrement()
MAtomic::postDecrement()
MAtomic::decrement()
MAtomic::set()
MAtomic::compareAndSwap()

ロックとアトミック操作のパフォーマンス

以下は、64 ビット版 Windows でのスピン ロックとミューテックス ロック、アトミック操作のコストに関するパフォーマンス値を示しています(OSX を除けば、他のプラットフォームも同様にはるかに低速です)。これらの数値を生成するプラグインは threadingLockTests と呼ばれ、ユーザが独自のシステムでテストを行うためのサンプル プラグインとして Maya に付属しています。これには OpenMP をサポートするコンパイラが必要です。このプラグインは、ロックされた領域内でコードがほとんど実際の並列処理を実行しないという極端な例です。ただし、激しい競合下でのこれらのロックの相対コストを示しています(ロックの競合は、あるスレッドがすでに保持しているロックを別のスレッドが取得しようとする場合に発生します。実行中のスレッドが増加すると、ロックの競合が起こる可能性が大幅に高まります。競合が激しくなると、パフォーマンスは大幅に低下します)。

さまざまなミューテックス ロックにアトミック操作の利点があります。また、ロックを実行しないコードは、アトミック実装よりもはるかに高速になります。可能な場合はロックを回避することをお勧めします。ロックを使用する場合はアトミック操作を使用します。アトミック操作を使用できない場合にかぎり、フル ミューテックス ロックまたはスピン ロックを使用します。

ロックの粒度は、それ自体が非常に複雑な項目です。一般的には、多数の並列処理が可能なため、疎粒度ではなく細粒度のロックが最も適切です。ただし、ロックの粒度が細かすぎると、膨大なシステム時間を消費し、コードが非常に複雑になります。課題は、ロックの粒度の最適なバランスを見つけることです。粒度が粗いロックは最も簡単であるため、このようなロックを初めて使用する場合にお勧めします。後は、パフォーマンスが向上しなくなるまで、徐々にロックの粒度を細かくしていきます。

ロック操作で最悪なのは、アプリケーションが処理をまったく進行できない場合です。

• 2 つのスレッドがそれぞれ異なるロックを実行してから互いに他方のスレッドが保持するロックを取得しようとした場合、デッドロックが発生します。それ以上の処理が不可能になり、アプリケーションはハングします。
• ライブロックはデッドロックと似ていますが、各スレッドがロックを過ぎて処理を進行せず、継続的にアクティブのままである点が異なります。たとえば、コードがデッドロックを検出しそこからロールバックはできるが、同じ評価の繰り返しを許可した場合に、サイクルが無限に繰り返される状況などです。

Maya API スレッド化サンプル - デフォーマ

Maya に付属のプラグイン splatDeformer はスレッド化デフォーマの実装サンプルです。このサンプルは、Maya ネイティブ API ではなく OpenMP を使用します。これは、スレッド化実装そのものではなくデフォーマのスレッド化に注目するためであり、OpenMP では、スレッド化の実装のために追加する必要のあるコード量が最小であるためです。

デフォーマは Maya スカルプト デフォーマに少し似ています。変形メッシュは選択したメッシュの修正に使用できます。このアルゴリズムは、デフォメーションを変形オブジェクトの最近接ポイントにスナップすることでメッシュのすべてのポイントに適用します。最近接ポイント操作は計算集約型の処理であるため、オーバーヘッドがスレッド化のあらゆる利点を帳消しにしてしまう一部のより単純なデフォーマとは異なり、スレッド化に適した選択肢です。

以下にこの実装の注意点をいくつか示します。

• すべての DG アクセスはスレッド化領域外で実行されます。例外はありますが、一般的に DG アクセスがスレッドセーフでないためです(下記のスレッドセーフな Maya API メソッドとクラスを参照)。
• すべての要素は、ループ トラバースを実行する iterator ではなく MItGeometry を使用して配列に読み取られます。これによりスレッドでの DG アクセスを回避し、iterator のスレッド化という困難な問題も回避します(ただし、Intel の OpenMP taskq 拡張機能では可能です)。
• MItGeometry には、単一の関数コール(allPositions() と setAllPositions())ですべてのポイントの読み取りと書き込みをすばやく行うことができるメソッドがあります。これは、ポイントを 1 つずつ照会して設定するよりもはるかに効率的です。Maya の MFnMesh でポイントを直接処理する場合は、新しいメソッドである getRawPoints() と getRawNormals() を使用すると、const ポインタが内部データに直接返されるためさらに高速になります。const を破棄してこのポインタを介して所定のデータを修正しないようにしてください。ほぼ確実にデータが破損します。
• MFnMesh の最近接ポイント メソッドはスレッドセーフではなく、固定メッシュの複数の評価にも不十分です。クラス MMeshIntersector はキャッシュ済みツリーのトラバースを使用するため、かなり高速でスレッドセーフでもあります。インターセクタをセットアップしてループ外で初期化してからループ内で評価されるため、並列処理の利点がすべて活かされます。
• meshPoint オブジェクトはループ内に割り当てる必要があるため、現在のスレッド スタックに作成されます。オブジェクトをループ外に割り当てると、ループが競合状態を引き起こします。誤ってループ外に宣言されている変数に書き込むのは、最初はスレッド化されていなかったコードにスレッド化を追加しようとするときによく起こる問題です。このような変数はすべて特定してください。可能なかぎりローカル変数のスコープで変数を宣言し、関数の先頭での変数宣言は回避することをお勧めします。これにより、さらに将来的なスレッド化処理がより簡単になるという利点が得られます。また、可能なかぎり変数を const としてループの前で宣言すると、コンパイル時にループ内からのこれらの変数への書き込みアクセスを把握できます。
• 値は共有配列に読み書きされるため、読み取りでのキャッシュ ミスや書き込みでの偽共有が生じる危険性があります。ただし、このようなループに対する既定の OpenMP トラバース スキームでは、最初のスレッドが最初の(nPoints/nThreads)要素を評価し、他のスレッドは同じサイズの隣接するチャンクを評価します。このアクセス パターンにより、キャッシュ ミスと偽共有のいずれも最小限に抑えられます。
• 最近接ポイント操作が失敗した場合、エバリュエータは即座に中止されず、エラーを示すステータス フラグが設定され、残りの繰り返し処理はスキップされます。この場合、OpenMP はスレッド化領域内からのコールの中断を許可しません。ただし、評価中の他のスレッドを中止するのに比べて、一般的に最も簡単なアプローチです。
• スレッド化領域の後に iterator が使用され、出力オブジェクトに値が書き戻されます。

拡張性はコードの順次部分によって制限されます。このため、スレッド化領域外でコードを最適化することが重要です。たとえば、最善の方法としては、DG から可能なかぎり大きなチャンクでデータの取得と設定を行うことが挙げられます。これにより DG のオーバーヘッドが最小限に抑えられます。複数のメソッドが MFnMesh に追加され、1 つの操作でさまざまなタイプのコンポーネントをすべて取得することができますが、特にこのような用途に適しています。当然ながら、一度に 1 つの要素を更新する iterator アプローチと比較すると、これらの配列は計算メソッド中は維持する必要があるため、メモリの使用量が増大する危険性があります。メソッド MFnMesh::getRawPoints は、ポインタを内部データに直接返すことによって最大速度を実現し、メモリのオーバーヘッドも回避します。

一部のデフォーマはウェイトをデータブロックにキャッシュします。データブロックからの読み取りは低速で、スレッドセーフでない可能性があります。デフォーマのウェイトはフレーム単位では変化しないことが多いため、このような場合、一度ウェイトを読み取ってデフォーマ クラス内のローカル配列に保存してから、キャッシュしたウェイト値を使用してスレッド化デフォーマの評価を行うのが最善の方法です。

Maya プラグインのシングルトン オブジェクトの初期化

一般的なコーディング パターンは、シングルトン オブジェクトの作成、あるいはソルバのグローバル データの初期化です。通常は以下が最も簡単な操作です。

static solver* singleton = 0
if (singleton == 0) {
   singleton = new Solver();
}

ただし、スレッド化コードの場合は非常に困難な問題になります。このパターンを実装するための最善のアプローチに関しては多くの文献がありますが、問題はオプティマイザが明らかにスレッドセーフな実装を損なうことが多いということです。明白なソリューションはロックの使用ですが、最初の構築にしか必要のない負荷の高い操作です。

一般的に、初期化のオーバーヘッドがあまり大きくない場合、プラグインの initialize() メソッドに組み込むと順次実行が保証されます。

オブジェクトが大規模であるかまたは構築に大きなリソースが必要な場合、あるいはプラグインが常に実行されるわけではない場合は、遅延評価を使用して必要なときだけオブジェクトを初期化します。以下に、このような場合に便利な実装を示します。ここでは、Maya に付属の MAtomic API クラスを利用します。

static Solver* singleton = 0
if (singleton == 0) {
    Solver* solver = new Solver();
    if(!MAtomic::compareAndSwap(&singleton, 0, solver)) {
       delete solver;
    }
}

コール時に複数のスレッドが if 条件を入力し、場合によっては同時に複数のソルバを作成します。compareAndSwap に到達した最初のスレッドは solverSingleton ポインタを新規ソルバのアドレスに設定し、後続のすべてのスレッドはソルバの作成終了後そのソルバのインスタンスを削除します。これは一見すると無駄が多いように思われますが、パフォーマンスに影響があるのは開始時のみで、後続のすべてのコード コールは単純なポインタを実行するだけでロック処理はまったく必要ないため、実際は非常に効率的です。

ソルバ コンストラクタに複数のスレッドが存在すると危険であるため、以下に代替テンプレートを示します。

static Solver* singleton = 0
static int doneInit=0;
if(MAtomic::compareAndSwap(&doneInit, 0, 1)) {
    singleton = new Solver();
    doneInit = 2;
}
while(doneInit != 2) {}; // spin-wait

このコードではソルバは必ず 1 度だけ初期化されます。コンストラクタが solver ポインタの初期化を実行したがその処理がまだ完了していない場合に他のスレッドのオブジェクトへのアクセスを防止するために、オブジェクトが完全に初期化されるまで終了しないスピンウェイト ループが適用されています。このアプローチの欠点は、アトミック操作が必要で、後続のすべてのコールに対して、なくとも 1 回の while ループのトラバースが必要になることです。また、コンパイラについては doneInit=2 の行をコンストラクタより上に配置しているという懸念事項があります。このため、ソルバ コンストラクタ コールに関する追加ロックが必要な場合があります。

これは、単純なタスクであってもスレッド化環境では注意が必要であることを示す良い例です。

スレッドセーフな Maya API メソッドとクラス

Maya API は非常に広範なため、現時点ですべての関数とクラスがスレッドセーフかどうかを示すことは不可能です。このセクションでは、スレッド化コードで頻繁にコールされる主要なクラスをいくつか説明します。

残念ながら、メソッドがスレッドセーフであると想定することは危険です。関数がインラインで直接確認できるものでなければ、常にコードがスレッドセーフではない危険性はあります。照会メソッドでさえも、照会により修正された内部状態をクラスが保存する場合があるため、安全ではないことがあります。

遅延評価を使用するクラスもあるため、特定のメソッドは、スレッド化領域外でコールして内部データ構造を更新することで「準備」する必要があります。たとえば、MFnMesh::getVertexNormal は、法線が最新であることを確認し、最新でない場合は再計算します。このように、法線が最新でない場合、この関数に対して 2 つの同時コールが発生するため危険性が生じます。ただし、1 つのコールが実行されて内部データ構造が更新されると、その初回の準備コール以降、オブジェクトが修正されないかぎり後続のコールはスレッドセーフになります。