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

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

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

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

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

As user thread implementations are typically entirely in userspace, context switching between user threads within the same process is extremely efficient because it does not require any interaction with the kernel at all: a context switch can be performed by locally saving the CPU registers used by the currently executing user thread or fiber and then loading the registers required by the user thread or fiber to be executed. Since scheduling occurs in userspace, the scheduling policy can be more easily tailored to the requirements of the program's workload.

However, the use of blocking system calls in user threads (as opposed to kernel threads) can be problematic. If a user thread or a fiber performs a system call that blocks, the other user threads and fibers in the process are unable to run until the system call returns. A typical example of this problem is when performing I/O: most programs are written to perform I/O synchronously. When an I/O operation is initiated, a system call is made, and does not return until the I/O operation has been completed. In the intervening period, the entire process is "blocked" by the kernel and cannot run, which starves other user threads and fibers in the same process from executing.

A common solution to this problem (used, in particular, by many green threads implementations) is providing an I/O API that implements an interface that blocks the calling thread, rather than the entire process, by using non-blocking I/O internally, and scheduling another user thread or fiber while the I/O operation is in progress. Similar solutions can be provided for other blocking system calls. Alternatively, the program can be written to avoid the use of synchronous I/O or other blocking system calls (in particular, using non-blocking I/O, including lambda continuations and/or async/await primitives^[10]).

Fibers are an even lighter unit of scheduling which are cooperatively scheduled: a running fiber must explicitly yield to allow another fiber to run, which makes their implementation much easier than kernel or user threads. A fiber can be scheduled to run in any thread in the same process. This permits applications to gain performance improvements by managing scheduling themselves, instead of relying on the kernel scheduler (which may not be tuned for the application). Some research implementations of the OpenMP parallel programming model implement their tasks through fibers.^[11][12] Closely related to fibers are coroutines, with the distinction being that coroutines are a language-level construct, while fibers are a system-level construct.

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

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

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 ]}、効率的なマルチスレッドプログラムの作成は困難です。特に、スレッド間の同期が頻繁に行われないように注意する必要があります。