スレッド（コンピューティング）

カーネルレベルでは、プロセスは1 つ以上のカーネル スレッドを含み、メモリやファイル ハンドルなどのプロセスのリソースを共有します。プロセスはリソースの単位であり、スレッドはスケジューリングと実行の単位です。カーネル スケジューリングは通常、一律にプリエンプティブに行われるか、あまり一般的ではありませんが協調的に行われます。ユーザー レベルでは、ランタイム システムなどのプロセスが、複数の実行スレッドをスケジュールできます。Erlang のように、これらのスレッドがデータを共有しない場合は、通常、同様にプロセスと呼ばれます^{[ 9 ]} 。一方、データを共有する場合は、特にプリエンプティブにスケジュールされている場合は、通常、 （ユーザー）スレッドと呼ばれます。協調的にスケジュールされたユーザー スレッドはファイバーとして知られています。異なるプロセスは、ユーザー スレッドを異なる方法でスケジュールできます。ユーザー スレッドは、さまざまな方法（1 対 1、多対 1、多対多）でカーネル スレッドによって実行できます。軽量プロセスという用語は、さまざまな意味でユーザー スレッドまたはユーザー スレッドをカーネル スレッドにスケジュールするためのカーネル メカニズムを指します。

プロセスはカーネルスケジューリングの重量単位であり、プロセスの作成、破棄、切り替えは比較的コストがかかります。プロセスはオペレーティングシステムによって割り当てられたリソースを所有します。リソースには、メモリ（コードとデータの両方用）、ファイルハンドル、ソケット、デバイスハンドル、ウィンドウ、およびプロセス制御ブロックが含まれます。プロセスはプロセス分離によって分離されており、ファイルハンドルや共有メモリセグメントの継承、または同じファイルを共有方式でマッピングするなどの明示的な方法を除き、アドレス空間やファイルリソースを共有しません（プロセス間通信を参照）。プロセスの作成または破棄は、リソースの取得または解放が必要なため、比較的コストがかかります。プロセスは通常プリエンプティブにマルチタスク化され、プロセス切り替えは、コンテキスト切り替えの基本コストに加えて、キャッシュフラッシュなどの問題により比較的コストがかかります（特に、プロセス切り替えは仮想メモリのアドレス指定を変更し、タグなし変換ルックアサイドバッファ（TLB）の無効化とフラッシュを引き起こします。これは特にx86で顕著です）。

カーネルスレッドは、カーネルスケジューリングの軽量単位です。各プロセスには少なくとも1つのカーネルスレッドが存在します。プロセス内に複数のカーネルスレッドが存在する場合、それらは同じメモリとファイルリソースを共有します。オペレーティングシステムのプロセススケジューラがプリエンプティブである場合、カーネルスレッドはプリエンプティブにマルチタスク化されます。カーネルスレッドは、スタック、プログラムカウンタを含むレジスタのコピー、およびスレッドローカルストレージ（存在する場合）以外のリソースを所有しないため、作成と破棄のコストは比較的低くなっています。スレッド切り替えも比較的コストが低く、コンテキストスイッチ（レジスタとスタックポインタの保存と復元）が必要ですが、仮想メモリを変更しないため、キャッシュに優しく（TLBを有効なまま維持）、効率的です。カーネルは、CPUの各コアに1つ以上のソフトウェアスレッドを割り当てることができ（マルチスレッドのサポート状況に応じて、カーネル自身に複数のソフトウェアスレッドを割り当てることも可能）、ブロックされたスレッドをスワップアウトできます。ただし、カーネルスレッドのスワップアウトには、ユーザスレッドよりもはるかに時間がかかります。

スレッドは、ユーザー空間ライブラリで実装される場合があり、その場合はユーザースレッドと呼ばれます。カーネルはこれらのスレッドを認識しないため、ユーザー空間で管理およびスケジューリングされます。一部の実装では、マルチプロセッサマシン（M:Nモデル）の利点を活用するために、複数のカーネルスレッドを基盤としてユーザースレッドを構築しています。仮想マシンによって実装されるユーザースレッドは、グリーンスレッドとも呼ばれます。

ユーザー スレッドの実装は通常、完全にユーザー空間で行われるため、同一プロセス内のユーザー スレッド間のコンテキスト スイッチは、カーネルとのやり取りを一切必要としないため、非常に効率的です。コンテキスト スイッチは、現在実行中のユーザー スレッドまたはファイバーが使用する CPU レジスタをローカルに保存し、次に実行予定のユーザー スレッドまたはファイバーに必要なレジスタをロードすることで実行できます。スケジューリングはユーザー空間で行われるため、スケジューリング ポリシーをプログラムのワークロードの要件に合わせて容易に調整できます。

しかし、ユーザー スレッド（カーネル スレッドとは対照的に）でブロッキング システム コールを使用すると問題が生じる可能性があります。ユーザー スレッドまたはファイバーがブロッキング システム コールを実行すると、そのシステム コールが戻るまで、プロセス内の他のユーザー スレッドとファイバーは実行できなくなります。この問題の典型的な例は、I/O を実行する場合です。ほとんどのプログラムは、I/O を同期的に実行するように記述されています。I/O 操作が開始されると、システム コールが呼び出され、I/O 操作が完了するまで戻りません。その間、プロセス全体がカーネルによって「ブロック」され、実行できなくなるため、同じプロセス内の他のユーザー スレッドとファイバーは実行できなくなります。

この問題に対する一般的な解決策（特に多くのグリーンスレッド実装で使用されている）は、内部で非ブロッキングI/Oを使用し、I/O操作の進行中に別のユーザースレッドまたはファイバーをスケジュールすることで、プロセス全体ではなく呼び出し元のスレッドをブロックするインターフェースを実装するI/O APIを提供することです。同様の解決策は、他のブロッキングシステムコールにも提供できます。あるいは、同期I/Oやその他のブロッキングシステムコールの使用を避けるようにプログラムを作成することもできます（特に、ラムダ継続やasync/ awaitプリミティブ^{[ 10 ]}を含む非ブロッキングI/Oを使用する）。

ファイバーは、協調的にスケジューリングされるさらに軽量なスケジューリング単位です。実行中のファイバーは、別のファイバーが実行できるように明示的に譲らなければならないため、カーネルスレッドやユーザースレッドよりも実装がはるかに容易です。ファイバーは、同じプロセス内の任意のスレッドで実行するようにスケジュールできます。これにより、アプリケーションは、カーネルスケジューラ（アプリケーションに合わせて調整されていない可能性がある）に依存するのではなく、スケジューリングを自身で管理することでパフォーマンスを向上させることができます。OpenMP 並列プログラミング モデルのいくつかの研究実装では、タスクをファイバー経由で実装しています。^{[ 11 ] [ 12 ]}ファイバーと密接に関連しているのはコルーチンですが、コルーチンは言語レベルの構成要素であるのに対し、ファイバーはシステムレベルの構成要素であるという違いがあります。

スレッドは、従来のマルチタスクオペレーティングシステムのプロセスとはいくつかの点で異なります。

• プロセスは通常独立しているが、スレッドはプロセスのサブセットとして存在する。
• プロセスはスレッドよりもはるかに多くの状態情報を保持しますが、プロセス内の複数のスレッドはプロセス状態だけでなく、メモリやその他のリソースも共有します。
• プロセスはそれぞれ独立したアドレス空間を持つが、スレッドはアドレス空間を共有する。
• プロセス間の相互作用は、システムが提供するプロセス間通信メカニズムを介してのみ行われる。
• 同一プロセス内のスレッド間のコンテキスト切り替えは、通常、プロセス間のコンテキスト切り替えよりも高速に発生します。

Windows NTやOS/2のようなシステムは、スレッドは安価でプロセスは高価であると言われています。他のオペレーティングシステムでは、アドレス空間の切り替えのコストを除けば、それほど大きな違いはありません。一部のアーキテクチャ（特にx86）では、アドレス空間の切り替えによってTLB（変換ルックアサイドバッファ）のフラッシュが発生します。

スレッドとプロセスの長所と短所は以下のとおりです。

• スレッドによるリソース消費量の削減：スレッドを使用することで、アプリケーションは複数のプロセスを使用する場合よりも少ないリソースで動作できます。
• スレッドの共有と通信の簡素化：プロセスはプロセス間通信（IPC）を実行するためにメッセージパッシングや共有メモリ機構を必要としますが、スレッドは既に共有しているデータ、コード、ファイルを介して通信できます。
• スレッドがプロセスをクラッシュさせる：スレッドは同じアドレス空間を共有しているため、スレッドによって不正な操作が実行されると、プロセス全体がクラッシュする可能性があります。したがって、1つのスレッドが不正な動作をすると、アプリケーション内の他のすべてのスレッドの処理が中断される可能性があります。

オペレーティングシステムは、スレッドをプリエンプティブまたは協調的にスケジュールします。マルチユーザーオペレーティングシステムは、コンテキストスイッチによる実行時間のよりきめ細かな制御のために、一般的にプリエンプティブマルチスレッドを好みます。しかし、プリエンプティブスケジューリングでは、プログラマが予期しないタイミングでスレッドのコンテキストスイッチが発生する可能性があり、ロックコンボイ、優先度反転、その他の副作用を引き起こすことがあります。一方、協調マルチスレッドでは、スレッドが実行制御を放棄することで、スレッドが完了するまで実行されることが保証されます。協調マルチタスクのスレッドがリソース待ちでブロックしたり、集中的な計算中に実行制御を譲渡せずに他のスレッドを飢餓状態にしたりすると、問題が発生する可能性があります。

2000年代初頭まで、ほとんどのデスクトップコンピュータはシングルコアCPUを1つしか搭載しておらず、ハードウェアスレッドはサポートされていませんでしたが、スレッド間の切り替えは一般的にプロセス全体のコンテキストスイッチよりも高速だったため、そのようなコンピュータでもスレッドは使用されていました。2002年、IntelはPentium 4プロセッサにハイパースレッディングという名称で同時マルチスレッドのサポートを追加しました。2005年には、デュアルコアのPentium Dプロセッサを、AMDはデュアルコアのAthlon 64 X2プロセッサを発表しました。

シングルプロセッサシステムでは、一般的にタイムスライシングによってマルチスレッドが実装されます。つまり、中央処理装置（CPU）が異なるソフトウェアスレッドを切り替えます。このコンテキスト切り替えは通常、ユーザーがスレッドやタスクが並列に実行されていると認識するほど頻繁に行われます（一般的なサーバー/デスクトップオペレーティングシステムでは、他のスレッドが待機している間、スレッドの最大タイムスライスは100～200ミリ秒に制限されることがよくあります）。マルチプロセッサまたはマルチコアシステムでは、複数のスレッドを並列に実行でき、各プロセッサまたはコアが同時に別のスレッドを実行します。ハードウェアスレッドを備えたプロセッサまたはコアでは、個別のソフトウェアスレッドを個別のハードウェアスレッドで同時に実行することもできます。

同一プロセス内のスレッドは、同じアドレス空間を共有します。これにより、並行して実行されるコードは密接に結合し、 IPCのオーバーヘッドや複雑さなしにデータを便利に交換できます。しかし、スレッド間で共有される場合、更新に複数のCPU命令を必要とする単純なデータ構造であっても、競合状態が発生しやすくなります。2つのスレッドが同時にデータ構造を更新しようとして、予期せずデータ構造が変更されてしまう可能性があるのです。競合状態によって引き起こされるバグは、再現や特定が非常に困難な場合があります。

これを防ぐために、スレッドアプリケーションプログラミングインターフェイス（API）は、同時アクセスからデータ構造をロックするためのミューテックスなどの同期プリミティブを提供します。単一プロセッサシステムでは、ロックされたミューテックスに侵入したスレッドはスリープする必要があり、コンテキストスイッチが発生します。マルチプロセッサシステムでは、スレッドは代わりにスピンロックでミューテックスをポーリングすることができます。これらの方法はいずれもパフォーマンスを低下させ、特にロックの粒度が細かすぎる場合、対称型マルチプロセッシング（SMP）システムのプロセッサがメモリバスを巡って競合する原因となる可能性があります。

その他の同期APIには、条件変数、クリティカルセクション、セマフォ、モニターなどがあります。

スレッドを扱う一般的なプログラミングパターンとして、スレッドプールがあります。これは、起動時に一定数のスレッドを作成し、タスクが割り当てられるまで待機させるものです。新しいタスクが到着すると、スレッドは起動し、タスクを完了すると再び待機状態に戻ります。これにより、タスクごとに比較的コストのかかるスレッドの作成と破棄を行う必要がなくなり、アプリケーション開発者はスレッド管理をライブラリやオペレーティングシステムに任せることができるため、スレッド管理の最適化が容易になります。

すべてのスレッドがビジー状態の場合、追加の作業項目は、実行可能なスレッドが見つかるまでキューに入れられます。^{[ 17 ]}

マルチスレッドアプリケーションは、シングルスレッドアプリケーションと比較して、以下の利点があります。

• 応答性：マルチスレッド化により、アプリケーションは入力に対して応答性を維持できます。シングルスレッドのプログラムでは、メイン実行スレッドが長時間実行されるタスクでブロックされると、アプリケーション全体がフリーズしたように見えることがあります。このような長時間実行されるタスクを、メイン実行スレッドと並行して実行されるワーカー スレッドに移動することで、アプリケーションはバックグラウンドでタスクを実行しながらユーザー入力に対して応答性を維持できます。一方、ほとんどの場合、マルチスレッド化はプログラムの応答性を維持する唯一の方法ではなく、同様の結果を得るためにノンブロッキング I/OやUnix シグナルが利用可能です。^{[ 18 ]}
• 並列化：マルチコアまたはマルチCPUシステムを使用するアプリケーションは、マルチスレッドを使用してデータとタスクを並列サブタスクに分割し、基盤となるアーキテクチャにスレッドの実行方法（1つのコアで同時実行、または複数のコアで並列実行）を管理させることができます。CUDA、OpenCL、DirectX 12などのGPUコンピューティング環境では、数十から数百のスレッドが多数のコア上のデータに対して並列実行されるマルチスレッドモデルが採用されています。これにより、システム利用率が向上し、（同期コストがメリットを相殺しない限り）プログラムの実行速度が速くなります。

マルチスレッドアプリケーションには、次のような欠点があります。

• 同期の複雑さと関連するバグ: スレッドプログラムでよく見られる共有リソースを使用する場合、プログラマは競合状態やその他の直感に反する動作を避けるよう注意する必要があります。データを正しく操作するには、スレッドが適切な順序でデータを処理するために、多くの場合、時間的にランデブーする必要があります。また、スレッドは、あるスレッドで共通データが読み取られたり上書きされたりする前に、別のスレッドによってデータが変更されるのを防ぐために、相互排他的な操作 (多くの場合、ミューテックスを使用して実装) を必要とする場合があります。このようなプリミティブを不用意に使用すると、デッドロック、ライブロック、またはリソースをめぐる競合が発生する可能性があります。また、マルチスレッド化によって、 RAMを含むシステムリソースの使用量が増加する可能性があります。 ^{[ 19 ]}エドワード A. リーが書いたように、「スレッドは逐次計算から小さな一歩のように見えるが、実際には大きな一歩である。スレッドは逐次計算の最も本質的で魅力的な特性、つまり理解可能性、予測可能性、決定性を捨て去る。計算モデルとしてのスレッドは極めて非決定的であり、プログラマの仕事はその非決定性を取り除くことになる。」 ^{[ 20 ]}
• テスト不可能であること。一般に、マルチスレッドプログラムは非決定論的であり、結果としてテスト不可能です。言い換えれば、マルチスレッドプログラムには、テストシステムでは決して現れず、本番環境でのみ現れるバグが容易に存在する可能性があります。^{[ 21 ] [ 20 ]}これは、スレッド間の通信を特定の明確に定義されたパターン（メッセージパッシングなど）に制限することで軽減できます。
• 同期にはコストがかかります。最新のCPUではスレッドコンテキストスイッチに最大100万CPUサイクルかかるため^{[ 22 ]}、効率的なマルチスレッドプログラムの作成は困難です。特に、スレッド間の同期が頻繁に行われないように注意する必要があります。