1つのプロセッサ上で実行される2つの実行スレッドを持つプロセス
プログラムvs.プロセスvs. スレッドの
スケジューリング、プリエンプション、コンテキストスイッチ

コンピュータサイエンスにおいて、実行スレッドとは、スケジューラ（通常はオペレーティングシステムの一部）によって独立して管理できる、プログラムされた命令の最小のシーケンスです。[1]多くの場合、スレッドはプロセスのコンポーネントです。

特定のプロセス内の複数のスレッドは、マルチスレッド機能を介して同時に実行され、メモリなどのリソースを共有しますが、異なるプロセス間ではこれらのリソースは共有されません。特に、プロセス内のスレッドは、実行コード、動的に割り当てられた変数、および非スレッドローカルな グローバル変数の値を常に共有します。

スレッドとプロセスの実装はオペレーティングシステムによって異なります。[2] [ページが必要]

歴史

スレッドは、1967年にIBMのバッチ処理オペレーティングシステムOS/360で「タスク」という名前で初めて登場しました。OS/360では、ユーザーに3種類のOS/360制御システム構成が提供され、そのうちの1つが可変タスク数マルチプログラミング（MVT）でした。Saltzer (1966)は、「スレッド」という用語をVictor A. Vyssotskyに帰しています。[3]

Machのスレッド実装は1986年の夏に発表されました。[4] 1987年にリリースされた OS/2 1.0はスレッドをサポートしました。 [5]スレッドを搭載した最初のWindowsバージョンは、1993年にリリースされた Windows NTでした。

2000年代初頭、CPUがマルチコアを利用するようになったため、ソフトウェアアプリケーションにおけるスレッドの使用はより一般的になりました。パフォーマンス向上のためにマルチコアを活用したいアプリケーションでは、マルチコアを活用するために並行処理を採用する必要がありました。[6]

スケジューリングはカーネルレベルまたはユーザーレベルで実行でき、マルチタスクはプリエンプティブまたは協調的に実行できます。これにより、関連する様々な概念が生まれます。

プロセス

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

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

カーネルスレッド

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

ユーザースレッド

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

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

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

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

繊維

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

スレッドとプロセス

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

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

スレッドとプロセスの利点と欠点は次のとおりです。

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

スケジュール

プリエンプティブスケジューリングと協調スケジューリング

オペレーティングシステムは、プリエンプティブまたは協調的にスレッドをスケジュールします。マルチユーザーオペレーティングシステムでは、コンテキストスイッチを介して実行時間をより細かく制御できるため、通常、プリエンプティブマルチスレッドが優先されます。ただし、プリエンプティブスケジューリングでは、プログラマが予期しない瞬間にスレッドのコンテキストスイッチが発生する可能性があり、ロックコンボイ、優先順位の逆転、またはその他の副作用が発生します。対照的に、協調的マルチスレッドでは、スレッドが実行の制御を放棄するため、スレッドが完了するまで実行されます。これは、協調的にマルチタスク化されたスレッドがリソースを待機してブロックしたり、集中的な計算中に実行の制御を譲らずに他のスレッドを飢えさせたりする場合に問題を引き起こす可能性があります。

シングルプロセッサシステムとマルチプロセッサシステム

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

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

スレッドモデル

1:1 (カーネルレベルのスレッド)

カーネル内のスケジュール可能なエンティティ[11]と1:1で対応するユーザ作成スレッドは、最もシンプルなスレッド実装です。OS /2とWin32は最初からこのアプローチを採用しており、LinuxではGNU Cライブラリがこのアプローチを実装しています（ NPTLまたは古いLinuxThreads経由）。このアプローチは、 Solaris、NetBSD、FreeBSD、macOS、iOSでも採用されています。

M:1 (ユーザーレベルのスレッド)

M :1モデルは、すべてのアプリケーションレベルのスレッドが1つのカーネルレベルのスケジュールされたエンティティにマップされることを意味します。[ 11]カーネルはアプリケーションスレッドを認識しません。このアプローチにより、コンテキストスイッチが非常に高速に実行でき、さらに、スレッドをサポートしない単純なカーネルでも実装できます。ただし、大きな欠点の1つは、マルチスレッドプロセッサまたはマルチプロセッサコンピュータのハードウェアアクセラレーションの恩恵を受けられないことです。同時に複数のスレッドがスケジュールされることはありません。[11]たとえば、スレッドの1つがI/O要求を実行する必要がある場合、プロセス全体がブロックされ、スレッドの利点を活用できません。GNUポータブルスレッドは、状態スレッドと同様に、ユーザーレベルのスレッドを使用します。

M:北（ハイブリッドスレッド）

M : Nは、 M個のアプリケーションスレッドをN個のカーネルエンティティ[11] 、または「仮想プロセッサ」にマッピングします。これは、カーネルレベル（「1:1」）スレッドとユーザーレベル（「 N :1」）スレッドの妥協案です。一般に、「M : N」スレッドシステムは、カーネルとユーザー空間の両方のコードに変更が必要になるため、カーネルスレッドやユーザースレッドよりも実装が複雑です[説明が必要]。M:N実装では、スレッドライブラリが、利用可能なスケジュール可能なエンティティ上でユーザースレッドをスケジュールする役割を担います。これにより、システムコールが回避されるため、スレッドのコンテキストスイッチが非常に高速になります。ただし、これにより複雑さが増し、優先度逆転の可能性が高くなるだけでなく、ユーザーランドスケジューラとカーネルスケジューラ間の広範かつ高価な調整がなければ、最適ではないスケジューリングが可能になります。

ハイブリッド実装例

  • NetBSD ネイティブ POSIX スレッド ライブラリ実装の古いバージョンで使用されるスケジューラ アクティベーション( 1:1 カーネルまたはユーザー空間実装モデルではなく、M : Nモデル)
  • Solarisオペレーティングシステムの古いバージョンで使用される軽量プロセス
  • PM2プロジェクトの Marcel 。
  • Tera- Cray MTA-2のOS
  • Haskell言語用の Glasgow Haskell コンパイラ (GHC)は、オペレーティング システム スレッドでスケジュールされる軽量スレッドを使用します。

Unixシステムにおけるスレッドモデルの歴史

SunOS 4.x は軽量プロセスまたは LWP を実装しました。NetBSD 2.x + とDragonFly BSD はカーネルスレッドとして LWP を実装しています (1:1 モデル)。SunOS 5.2 から SunOS 5.8 および NetBSD 2 から NetBSD 4 は、各カーネルスレッドで 1 つ以上のユーザーレベルスレッドを多重化する 2 レベルモデルを実装しました (M:N モデル)。SunOS 5.9 以降および NetBSD 5 ではユーザースレッドのサポートが削除され、1:1 モデルに戻りました。[12] FreeBSD 5 は M:N モデルを実装しました。FreeBSD 6 は 1:1 と M:N の両方をサポートし、ユーザーは /etc/libmap.conf を使用して特定のプログラムでどちらを使用するかを選択できました。FreeBSD 7 以降では、1:1 がデフォルトになりました。FreeBSD 8 は M:N モデルをサポートしなくなりました。

シングルスレッドプログラムとマルチスレッドプログラム

コンピュータプログラミングにおいて、シングルスレッドとは、一度に1つの命令を処理することです。 [13]変数のセマンティクスとプロセス状態の形式的な分析では、シングルスレッドという用語は「単一のスレッド内でのバックトラック」という意味で異なる意味で使用されることもあり、これは関数型プログラミングコミュニティで一般的です。[14]

マルチスレッドは、主にマルチタスクOSで採用されています。マルチスレッドは、1つのプロセス内で複数のスレッドを共存させることを可能にする、広く普及したプログラミングおよび実行モデルです。これらのスレッドはプロセスのリソースを共有しますが、それぞれ独立して実行できます。スレッドプログラミングモデルは、開発者に同時実行の有用な抽象化を提供します。また、マルチスレッドを1つのプロセスに適用することで、マルチプロセスシステム 上での並列実行を実現することもできます。

マルチスレッドライブラリは、関数を引数として受け取る新しいスレッドを作成するための関数呼び出しを提供する傾向があります。これにより、渡された関数の実行を開始し、関数が返された時点で終了する並行スレッドが作成されます。スレッドライブラリは、データ同期機能も提供しています。

スレッドとデータの同期

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

これを防ぐため、スレッド化アプリケーション・プログラミング・インターフェース（API）は、データ構造を同時アクセスからロックするためのミューテックスなどの同期プリミティブを提供しています。ユニプロセッサシステムでは、ロックされたミューテックスに遭遇したスレッドはスリープ状態となり、コンテキストスイッチがトリガーされます。マルチプロセッサシステムでは、スレッドは代わりにスピンロックでミューテックスをポーリングする場合があります。これらの動作はどちらもパフォーマンスを低下させ、対称型マルチプロセッシング（SMP）システムのプロセッサ間でメモリバスの競合を引き起こす可能性があります。特にロックの 粒度が細かすぎる場合はその傾向が顕著です。

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

スレッドプール

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

マルチスレッドプログラムとシングルスレッドプログラムの長所と短所

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

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

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

  • 同期の複雑さと関連するバグ：スレッドプログラムに典型的な共有リソースを使用する場合、プログラマーは競合状態やその他の直感に反する動作を回避するよう注意する必要があります。データを正しく操作するためには、スレッドが適切な順序でデータを処理するため、適切なタイミングでランデブーを行う必要があることがよくあります。また、スレッドでは、共通データが一方のスレッドで読み込まれたり上書きされたりしているときに、もう一方のスレッドで変更されたりすることを防ぐために、相互に排他的な操作（多くの場合、ミューテックスを使用して実装されます）が必要になることもあります。このようなプリミティブを不注意に使用すると、デッドロック、ライブロック、またはリソース競合が発生する可能性があります。Edward A. Leeは次のように述べています。「スレッドはシーケンシャル計算から少し離れたところにあるように見えますが、実際には大きな一歩です。スレッドは、シーケンシャル計算の最も本質的で魅力的な特性、すなわち理解可能性、予測可能性、そして決定性を放棄しています。計算モデルとしてのスレッドは極めて非決定的であり、プログラマーの仕事はその非決定性を取り除く作業になります。」[16]
  • テスト不可能であること。一般的に、マルチスレッドプログラムは非決定論的であり、その結果、テスト不可能となります。言い換えれば、マルチスレッドプログラムには、テストシステムでは決して現れず、本番環境でのみ現れるバグが容易に存在する可能性があります。[17] [16]これは、スレッド間通信を特定の明確に定義されたパターン（メッセージパッシングなど）に制限することで軽減できます。
  • 同期コスト。現代のCPUではスレッドコンテキストスイッチに最大100万CPUサイクルかかるため[18]、効率的なマルチスレッドプログラムの作成が困難になります。特に、スレッド間同期が頻繁に発生しないように特別な注意を払う必要があります。

プログラミング言語のサポート

多くのプログラミング言語は、何らかの形でスレッドをサポートしています。

  • IBM PL/I (F) は、1960年代後半からマルチスレッド（マルチタスクと呼ばれる）のサポートを実装しており、これは最適化コンパイラ以降のバージョンにも引き継がれました。IBM Enterprise PL/I コンパイラでは、新しいモデル「スレッド」API が導入されました。どちらのバージョンも PL/I 標準には含まれていませんでした。
  • CおよびC++の多くの実装はスレッドをサポートし、オペレーティングシステムのネイティブスレッドAPIへのアクセスを提供しています。スレッド実装のための標準化されたインターフェースは、C関数ライブラリ呼び出しのセットであるPOSIX Threads（Pthreads）です。OSベンダーは自由にインターフェースを実装できますが、アプリケーション開発者は複数のプラットフォームで同じインターフェースを使用できる必要があります。Linuxを含むほとんどのUnixプラットフォームはPthreadsをサポートしています。Microsoft Windowsには、 beginthreadのようなマルチスレッド用のスレッド関数のセットがprocess.hインターフェースに用意されています。
  • Java、Python、.NET Frameworkなどの一部の高水準（通常はクロスプラットフォーム）プログラミング言語は、実行時のスレッド実装におけるプラットフォーム固有の差異を抽象化しながら、開発者にスレッド処理を公開しています。他の多くのプログラミング言語や言語拡張も、並行性とスレッド処理の概念を開発者から完全に抽象化しようとしています（Cilk、OpenMP、Message Passing Interface（MPI））。一部の言語は、並行性やスレッドを必要とせず、代わりに逐次並列処理（特にGPUを使用）向けに設計されています（Ateji PX、CUDA）。
  • いくつかのインタプリタ型プログラミング言語（ Rubyの場合はRuby MRI、 Pythonの場合はCPython ）は、スレッド化と並行性をサポートしているものの、グローバルインタプリタロック（GIL）のため、スレッドの並列実行はサポートしていません。GILはインタプリタが保持する排他ロックであり、インタプリタが2つ以上のスレッドで同時にアプリケーションコードを解釈することを防ぎます。これは、マルチコアシステムにおける並列性を実質的に制限します。また、プロセッサ依存のスレッド（プロセッサを必要とする）のパフォーマンスも制限しますが、I/O依存やネットワーク依存のスレッドにはそれほど影響しません。Thread拡張を使用するTclなど、他のインタプリタ型プログラミング言語の実装では、データとコードをスレッド間で明示的に「共有」する必要があるアパートメントモデルを使用することで、GILの制限を回避しています。Tclでは、各スレッドは1つ以上のインタプリタを持ちます。
  • CUDAなどのデータ並列計算用に設計されたプログラミングモデルでは、スレッドの配列が、メモリ内のデータを見つけるためにスレッドIDのみを使用して、同じコードを並列に実行します。つまり、各スレッドが異なるメモリセグメントに対して同じ操作を実行するようにアプリケーションを設計する必要があります。そうすることで、各スレッドが並列に動作し、GPUアーキテクチャを利用できるようになります。
  • Hardware description languages such as Verilog have a different threading model that supports extremely large numbers of threads (for modeling hardware).

See also

References

  1. ^ Lamport, Leslie (September 1979). "How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs" (PDF). IEEE Transactions on Computers. C-28 (9): 690–691. Bibcode:1979ITCmp.100..690L. doi:10.1109/tc.1979.1675439. S2CID 5679366.
  2. ^ Tanenbaum, Andrew S. (1992). Modern Operating Systems. Prentice-Hall International Editions. ISBN 0-13-595752-4.
  3. ^ Saltzer, Jerome Howard (July 1966). Traffic Control in a Multiplexed Computer System (PDF) (Doctor of Science thesis). p. 20.
  4. ^ "Mach: A New Kernel Foundation for UNIX Development" (PDF). 1986 Summer USENIX Technical Conference & Exhibition Proceedings. 1986. p. 93.
  5. ^ "Microsoft Operating System/2 Programmer's Guide" (PDF).
  6. ^ Sutter, Herb (March 2005). "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software". Dr. Dobb's Journal. 30 (3).
  7. ^ "Erlang: 3.1 Processes".
  8. ^ Ignatchenko, Sergey. Eight Ways to Handle Non-blocking Returns in Message-passing Programs: from C++98 via C++11 to C++20. CPPCON. Archived from the original on 2020-11-25. Retrieved 2020-11-24.{{cite AV media}}: CS1 maint: bot: 元のURLステータス不明（リンク）
  9. ^ Ferat, Manuel; Pereira, Romain; Roussel, Adrien; Carribault, Patrick; Steffenel, Luiz-Angelo; Gautier, Thierry (September 2022). "Enhancing MPI+OpenMP Task Based Applications for Heterogeneous Architectures with GPU support" (PDF). OpenMP in a Modern World: From Multi-device Support to Meta Programming. IWOMP 2022: 18th International Workshop on OpenMP. Lecture Notes in Computer Science. Vol. 13527. pp. 3–16. doi:10.1007/978-3-031-15922-0_1. ISBN 978-3-031-15921-3. S2CID 251692327.
  10. ^ 岩崎 真太郎; アメル アブデルハリム; 田浦 健次郎; ソ サンミン; バラジ パヴァン. BOLT: ユーザーレベルスレッドによるOpenMP並列領域の最適化(PDF) . 第28回国際並列アーキテクチャおよびコンパイル技術会議.
  11. ^ abcd シルバーシャッツ, アブラハム; ガルビン, ピーター・ベア; ガニエ, グレッグ (2013).オペレーティングシステムのコンセプト(第9版). ホーボーケン, ニュージャージー: ワイリー. pp.  170– 171. ISBN 9781118063330。
  12. ^ 「Solarisオペレーティング環境におけるマルチスレッド」(PDF) 2002年。2009年2月26日時点のオリジナル(PDF)からのアーカイブ。
  13. ^ Menéndez, Raúl; Lowe, Doug (2001). Murach's CICS for the COBOL Programmer. Mike Murach & Associates. p. 512. ISBN 978-1-890774-09-7。
  14. ^ O'Hearn, Peter William; Tennent, RD (1997). ALGOL類似言語. 第2巻. Birkhäuser Verlag . p. 157. ISBN 978-0-8176-3937-2。
  15. ^ Ignatchenko, Sergey (2010年8月). 「シングルスレッド：バック・トゥ・ザ・フューチャー？」Overload (97). ACCU : 16–19 .
  16. ^ ab Lee, Edward (2006年1月10日). 「スレッドの問題」. カリフォルニア大学バークレー校.
  17. ^ Ignatchenko, Sergey (2015年8月). 「ビジネスロジックレベルでのマルチスレッドは有害であると考えられる」. Overload (128). ACCU : 4–7 .
  18. ^ 'No Bugs' Hare (2016年9月12日). 「CPUクロックサイクルでの操作コスト」

さらに読む

  • David R. Butenhof: POSIX スレッドによるプログラミング、Addison-Wesley、ISBN 0-201-63392-2
  • Bradford Nichols、Dick Buttlar、Jacqueline Proulx Farell著：Pthreadsプログラミング、O'Reilly & Associates、ISBN 1-56592-115-1
  • ポール・ハイド：Javaスレッドプログラミング、サムズ、ISBN 0-672-31585-8
  • Jim Beveridge、Robert Wiener: Win32 でのマルチスレッドアプリケーション、Addison-Wesley、ISBN 0-201-44234-5
  • ウレシュ・ヴァハリア著『Unix Internals: the New Frontiers』、プレンティス・ホール、ISBN 0-13-101908-2
ウィキバーシティにはプロセスとスレッドに関する学習リソースがあります。
オペレーティングシステム/プロセスとスレッド