最新のコンピューターには、複数の処理コアがあります。 各コアが継続的にビジー状態を維持できるように十分な処理があると仮定します。 それらには、計算作業項目のキューが割り当てられます。 または、スケジューラによって完了するスレッド。
これらのスレッドの実行中に、新しいスレッドまたは作業項目を生成することができます。 これらは、同時に処理できる個別のスレッドです。 結果をスポーン プログラムにフィードバックするか、完全に分離したままにしておく必要があるかもしれません。 通常、これらの子スレッドは、親と同じ処理コアに割り当てられます。
これはすべて、すべてのコアがビジー状態に保たれていることを前提としています。 これは、スレッドが終了しないか、新しいスレッドが既存のスレッドの終了と同じかそれ以上の速度で生成された場合に発生します。 ただし、現実の世界では、特にエンドユーザーのコンピューティング デバイスでは、長期的なワークロードがそれほど単純になることはめったにありません。 最終的には、処理コアが割り当てられたすべてのタスクを完了する可能性があります。 これが発生すると、アイドル状態で潜在的なパフォーマンスを浪費するのではなく、代わりに他の処理コアの作業キューをチェックし、それらから作業項目を盗みます。
メリットとデメリット
ワーク スチールとは、アイドル状態のプロセッシング コアが、完了するためにアクティブにワークを検索することを意味します。 これにより、プロセッサ全体の大部分がアイドル状態になる可能性がなくなり、役に立ちます。 ただし、ワークスティーリングにはいくつかの代償が伴います。 たとえば、新しいプロセッシング コアは、関連するデータをキャッシュ メモリにロードする必要があります。
特に、共有キャッシュ層によって提供されるのではなく、システム RAM から要求する必要がある場合は、時間がかかることがあります。 元のプロセッサがその時間枠内でその作業項目を再開できた可能性があり、全体的な実行が高速化されました。 これは、ワークアイテムが盗まれた元のプロセッシング コアがその処理を開始していない場合にも当てはまります。 一部のキャッシュされた値は、親スレッドと子スレッドの間で同一である場合があります。
実装
いくつかのプログラミング言語には、専用プロセッサで直接作業をスケジュールできるランタイムがあります。 たとえば、Cilk プログラミング言語、Rust Tokio ランタイム、および .Net Task Parallel Library でこれを行うことができます。 あるいは、オペレーティング システムが実際のプロセッサ時間のスケジューリングを担当している場合もあります。 このプログラムでは、オペレーティング システムによってスケジュールされる「ワーカー スレッド」のプールにタスクを追加するだけです。
これは、プログラムが処理コアへの専用の直接アクセスを持っていないが、他のプロセスとアクセスを共有する必要があるシステムで発生します。 このシナリオでは、アイドル状態のスレッドが繰り返し盗まれないように、細心の注意を払う必要があります。
ワークアイテムを盗むために選択する方法には、さまざまなアプローチがあります。 元のコンセプトでは、アプローチは別のランダムなコアを選択することでした。 キューに 1 つ以上の作業項目がある場合は、最後の 1 つを取ります。 子プロセスが元のプロセッサによってすぐに実行されるかどうかの設定に応じて。 または、プロセッサのキューにプッシュされ、親プロセスが実行され続けると、親スレッドまたは子スレッドが盗まれます。
これはすべて、使用可能なプロセッサ間で負荷が均等に分散されるようにする負荷分散技術であるワーク スティーリングとして要約できます。 そうすれば、すべてのプロセッサが何かを助けます。
結論
ワーク スチールは、マルチコア CPU で自動的に発生するプロセスです。 各コアには、実行するタスクのキューがあります。 プロセッサがタスクを完了すると、別の処理コアのキューから別のタスクを盗みます。 これにより、プロセッサが一部のコアをアイドル状態にし、他のコアには実行するタスクのキューが残っているのを防ぐことができます。