あなたの質問は、一般的なツリー ウォーク フォーク テクニックのようです。再帰するたびに、代わりに別の同時操作を開始します (スレッドプールにエンキューするなど)。ただし、最後にすべてのサブブランチが終了するまで待つ必要があります。開始する各サブ操作のカウントダウン イベントに 1 を追加し、各サブ操作の終了時にそれを知らせるだけです。子操作ごとに追加するまでシグナルを送信しないようにアルゴリズムを調整する限り、安全に実行できます。
前もってカウントを知る必要はなく、ルートで1にするだけで、子にフォークするたびに1を追加し、それぞれの最後にシグナルを送ることを追加する必要があります。動的に初期費用なしであらゆるツリーを処理します。
CountdownEvent には Add メソッドがあり、飛行中にカウントを増やすことができます。
それは理にかなっていますか?私はあなたが達成しようとしていることからは程遠いかもしれません。
ただし、指定したとおりに動作する CountdownEvent が本当に必要な場合は、いくつかのインターロックされた操作をクラスにラップして、指定したことを実行するのは非常に簡単です。
ただし、CountdownEvent は羽のように軽量に構築されており、信号が送られる前に誰も待たなければほとんど無料です。高価なケースでは、最悪のケースでは、信号へのカーネル遷移と待機へのカーネル遷移を 1 つだけ行う必要があるタスク (など) の数に関係なく、最適です。
あなたが提案したものを実装するには、イベントのシグナリングとリセットに関する同期が必要です。カウントダウン イベントは 1 つの単純な原則に依存しています。Signal 呼び出しで非ゼロからゼロへの遷移のみがイベントを通知できる可能性があります。複数のスレッドが一度に値を変更することはできない (インターロックされている) ため、競合は発生しません。そのため、1 つのスレッドのみがイベント オブジェクトにシグナルを送ろうとすることができます (これにより、他の待機中のスレッドが目覚めます)。完全。
ただし、複数のスレッドで設定とリセットを行う場合は、設定とリセットを同期する必要があります。これは、カウントが数回変動する可能性があり、複数のスレッドがすべて同時にイベントを設定またはリセットしようとするためです。(イベントの設定、リセット、および待機はすべて、カーネルの移行を行い、コンテキスト スイッチを発生させる必要があるため、すべてコストがかかります)。セット/リセット遷移を保護するために何かを同期しない限り、機能しません。これを CountdownEvent に追加すると、ほぼ最適ではなくなり、大幅にコストが高くなります。