同期

要件: count>=0。連続で n の先行を生成して待つ場合、count が n+1 であること。 その他の場合、count が n であること。

効果: refcount 属性を count に設定します。

refcount 属性をアトミックにインクリメントします。

refcount 属性をアトミックにデクリメントします。

戻り値: refcount 属性の新しい値。

要件: refcount=n+1。ここで、n はまだ実行している先行の数。

効果: refcount が 1 になるまでレディプールのタスクを実行します。 その後、タスクの task_group_context が concurrent_wait を指定する場合は refcount=1 のまま変更しません。その他の場合、refcount を 0 に設定します。 下記の図は、状態遷移を要約したものです。

wait_for_all() は、次の条件がすべて満たされる場合、タスクと暗黙的に関連する task_group_context のキャンセル状態を自動的にリセットします。

• コンテキストを指定しないでタスクが割り当てられた。

• 呼び出しスレッドが、インテル® スレッディング・ビルディング・ブロック (インテル® TBB) のワーカースレッドではなく、ユーザーが作成したスレッドである。

• スレッドによる wait_for_all() の最も外側の呼び出しである。

wait_for_all の効果

タスク t をレディプールに格納して直ちにリターンします。

t の successor が NULL でない場合、子タスクが完了すると successor.refcount が非同期にデクリメントされるため、successor は子タスクが作成される前に set_ref_count を呼び出す必要があります。 ライブラリーのデバッグバージョンは、set_ref_count への必要な呼び出しが行われなかったり、または遅すぎる場合を検出します。

list の各タスクで spawn を実行して list をクリアするのと等価ですが、より効率的です。 list が空の場合、何も起こりません。

要件: this のほかの先行がすでに作成されていること。 タスク t が NULL 以外の successor 属性を含むこと。 t から呼び出しタスクまで successor リンクのチェーンがあること。 通常、このチェーンは単一のリンクを含みます。 つまり、t は this の先行です。

効果: {spawn(t); wait_for_all();} に似ていますが、多くの場合より効率的です。 さらに、task が現在のスレッドによって実行されることを保証します。 この制約は、同期を単純化する場合があります。 下記の図は、状態遷移を要約したものです。 上記の図に似ていますが、タスク t は n 番目のタスクです。

spawn_and_wait_for_all の効果

{spawn(list); wait_for_all();} に似ていますが、多くの場合より効率的です。

要件: タスク root のメモリーが task::allocate_root() で割り当てられていること。

効果: root の parent 属性に未定義の値を設定して、「execute() の処理」セクションで説明されているように root を実行します。 root が再利用されていなければ、後で root を破棄します。

要件: root_list の各タスク・オブジェクト t が static void spawn_root_and_wait( task& root ) の要件を満たしていること。

効果: root_list の各タスク・オブジェクト t で、spawn_root_and_wait(t) を並列に実行します。 「static void spawn_root_and_wait( task& root )」セクションで、spawn_root_and_wait(t) の動作を説明しています。

タスクの完了を明示的に待っているスレッドがない場合でも、タスクはワーカースレッドにより最終的に実行されるようにスケジュールされます。 ワーカースレッドの合計が 0 の場合、キューに入れられたタスクを実行する追加の特別なワーカースレッドが作成されます。

キューに入れられたタスクは、先着順に処理されます。