ユーザーレベルのスレッドとカーネルがサポートするスレッドの違いは？
私はこのトピックに基づいていくつかのメモを調べてきましたが、一般的なスレッドについては理解していますが、ユーザーレベルのスレッドとカーネルレベルのスレッドの違い =。
プロセスは基本的に複数のスレッドまたは単一のスレッドで構成されていますが、これらのスレッドは前述の2つのタイプですか？
私が理解したことから、カーネルがサポートするスレッドは、ユーザーレベルのスレッドでは利用できないシステムコールやその他の用途のためにカーネルにアクセスできます。
では、ユーザーレベルのスレッドは、プログラマが作成したスレッドであり、カーネルがサポートするスレッドを使用して、その状態が原因で通常は実行できなかった操作を実行できますか？
編集：質問は少しわかりにくいので、2つの異なる方法で答えています。
OSレベルのスレッドとグリーンスレッド
明確にするために、私は通常、「カーネルレベルのスレッド」ではなく「OSレベルのスレッド」または「ネイティブスレッド」と言います（以下の元の回答では「カーネルスレッド」と混同します）。 OS。ほとんどの言語はそれらをサポートしています。 （C、最近のJavaなど）これらは、問題の防止に100％責任があるため、使用が非常に困難です。一部の言語では、ネイティブデータ構造（ハッシュや辞書など）でさえ、余分なロックコードなしで壊れます。
OSスレッドの反対は、言語によって管理される 緑のスレッド です。これらのスレッドには、言語に応じてさまざまな名前が付けられます（Cのコルーチン、Goのゴルーチン、Rubyのファイバーなど）。これらのスレッドは言語内にのみ存在し、OSには存在しません。言語はコンテキストスイッチを選択するため（つまり、ステートメントの最後）、微妙な競合状態のTONS（部分的にコピーされた構造の表示、またはほとんどのデータ構造のロックが必要）を防ぎます。プログラマーは「ブロッキング」呼び出し（つまり、data = file.read()）を見ますが、言語はそれをOSへの非同期呼び出しに変換します。この言語は、結果を待つ間にother緑のスレッドの実行を許可します。
グリーンスレッドはプログラマーにとってはるかに単純ですが、パフォーマンスは異なります。スレッドがたくさんある場合、グリーンスレッドはCPUとRAMの両方にとって優れている可能性があります。一方、ほとんどのグリーンスレッド言語は、複数のコアを利用できません。 （もうシングルコアのコンピューターや電話を購入することもできません！）。また、不良ライブラリは、OSの呼び出しをブロックすることにより、言語全体を停止させる可能性があります。
両方の長所は、CPUごとに1つのOSスレッドを持ち、OSスレッドに魔法のように移動する多くのグリーンスレッドを持つことです。 GoやErlangなどの言語でこれを行うことができます。
ユーザーレベルのスレッドでは利用できないシステムコールやその他の用途
これは半分しか真実ではありません。はい、OSを自分で呼び出すと簡単に問題を引き起こす可能性があります（つまり、ブロックしている何かを実行します）。しかし、通常、言語には置換があります。これらの置換はカーネルを呼び出しますが、あなたが思っているのとは少し異なります。
カーネルスレッドとユーザースレッド
編集：これは私の最初の答えですが、それはユーザー空間スレッドとカーネルのみのスレッドに関するものであり、（後から見て）おそらく問題ではありませんでした。
ユーザースレッドとカーネルスレッドはまったく同じです。 （/ proc /を見ると、カーネルスレッドもあることがわかります。）
ユーザースレッドは、ユーザー空間コードを実行するスレッドです。しかし、いつでもカーネル空間を呼び出すことができます。高度なセキュリティレベルでカーネルコードを実行している場合でも、「ユーザー」スレッドと見なされます。
カーネルスレッドは、カーネルコードのみを実行し、ユーザー空間プロセスに関連付けられていないスレッドです。これらは「UNIXデーモン」に似ていますが、カーネルのみのデーモンです。したがって、カーネルはマルチスレッドプログラムであると言えます。たとえば、スワップ用のカーネルスレッドがあります。これにより、すべてのスワップの問題が強制的に「シリアル化」されて単一のストリームになります。
ユーザースレッドが何かを必要とする場合、カーネルを呼び出し、そのスレッドをスリープ状態としてマークします。後で、スワップスレッドはデータを見つけるため、ユーザースレッドを実行可能としてマークします。その後も、「ユーザースレッド」は何も起こらなかったようにカーネルからユーザーランドに戻ります。
実際、allスレッドはカーネルスペースで開始されます。これは、clone（）操作がカーネルスペースで発生するためです。 （そして、ユーザー空間で新しいプロセスに「戻る」ことができる前に、多くのカーネルアカウンティングがあります。）
比較に入る前に、まずスレッドとは何かを理解しましょう。スレッドは、独立したプロセスのドメイン内の軽量プロセスです。プロセスが重く、多くのリソースを消費するため、さらに重要なことは、
2つの別個のプロセスはメモリ空間を共有できません。
テキストエディタを開いたとしましょう。これは、独立したアドレス可能な場所でメモリ内で実行される独立したプロセスです。このプロセスには、グラフィックの挿入、スペルチェックなど、多くのリソースが必要です。これらの機能ごとに個別のプロセスを作成し、メモリ内で独立して維持することは不可能です。これを回避するには、
単一のプロセス内に複数のスレッドを作成できます。これにより、プロセス内に独立して存在する共通のメモリ空間を共有できます。
では、質問に1つずつ戻ります。
ユーザーレベルのスレッドとカーネルレベルのスレッドの違いについて、私は本当に確信が持てません。
スレッドは、ユーザーレベルスレッドとカーネルレベルスレッドに大別されます。実行のドメイン。 1つまたは多くのユーザースレッドが1つまたは多くのカーネルスレッドにマップされる場合もあります。
-ユーザーレベルのスレッド
ユーザーレベルのスレッドは、主にアプリケーションがこれらのスレッドを作成してメインメモリでの実行を維持するアプリケーションレベルにあります。必要な場合を除き、これらのスレッドはカーネルスレッドと独立して動作します。
これらは、多くのレジスタを参照する必要がなく、コンテキストの切り替えがカーネルレベルのスレッドよりもはるかに高速であるため、作成が簡単です。
ユーザーレベルのスレッドは、ほとんどがアプリケーションレベルで変更を引き起こす可能性があり、カーネルレベルのスレッドは独自のペースで実行を続けます。
-カーネルレベルスレッド
これらのスレッドは、進行中のプロセスからほとんど独立しており、オペレーティングシステムによって実行されます。
これらのスレッドは、メモリ管理、プロセス管理などのタスクのためにオペレーティングシステムに必要です。
これらのスレッドは、オペレーティングシステムに必要なプロセスを維持、実行、報告するため、カーネルレベルのスレッドは作成と管理がより高価であり、これらのスレッドのコンテキストスイッチングは低速です。
ほとんどのカーネルレベルのスレッドは、ユーザーレベルのスレッドによってプリエンプトされることはできません。
MS DOS written for Intel 8088 didn't have dual mode of operation. Thus, a user level process had the ability to corrupt the entire operating system.
-カーネルスレッドにマップされたユーザーレベルのスレッド
これはおそらく最も興味深い部分です。多くのユーザーレベルのスレッドは、カーネルレベルのスレッドにマップされ、カーネルレベルのスレッドはカーネルと通信します。
顕著なマッピングの一部は次のとおりです。
一対一
1つのユーザーレベルのスレッドが1つのカーネルスレッドのみにマップされる場合。
利点：各ユーザースレッドは1つのカーネルスレッドにマップされます。ユーザースレッドの1つがブロッキングシステムコールを発行しても、他のプロセスは影響を受けません。
欠点：すべてのユーザースレッドは相互作用するために1つのカーネルスレッドを必要とし、カーネルスレッドは作成と管理に費用がかかります。
多対一
多くのユーザースレッドが1つのカーネルスレッドにマップされる場合。
利点：同様のユーザースレッドを1つのカーネルスレッドにマップできるため、複数のカーネルスレッドは必要ありません。
欠点：ユーザースレッドの1つがブロッキングシステムコールを発行した場合でも、そのカーネルスレッドにマップされている他のすべてのユーザースレッドはブロックされます。
また、カーネルは一度に1つのカーネルスレッドのみを処理するため、適切なレベルの同時実行性は実現できません。
多対多
多くのユーザースレッドが同等またはより少ない数のカーネルスレッドにマップされる場合。プログラマは、ユーザースレッドの数をカーネルスレッドの数にマッピングするかどうかを決定します。ユーザースレッドの一部は、1つのカーネルスレッドのみにマップされる場合があります。
利点：高いレベルの並行性が実現します。プログラマは、ブロッキングシステムコールを発行する可能性のある潜在的に危険なスレッドを決定し、それらを1対1のマッピングで配置できます。
欠点：カーネルスレッドの数は、慎重に決定しないと、システムの速度を低下させる可能性があります。
あなたの質問の他の部分：
カーネルがサポートするスレッドは、システムコールやユーザーレベルのスレッドでは利用できない他の用途のためにカーネルにアクセスできます。
それでは、ユーザーレベルのスレッドは、プログラマが作成したスレッドであり、カーネルがサポートするスレッドを利用して、その状態が原因で通常は実行できなかった操作を実行できますか？
部分的に正しい。カーネルスレッドはOSのプロセスを実行するため、ほとんどすべてのカーネルスレッドがシステムコールやその他の重要な割り込みにアクセスできます。ユーザースレッドは、これらの重要な機能の一部にアクセスできません。例えばテキストエディタは、プロセスの物理アドレスを変更する機能を持つスレッドを撮影することはできません。しかし、必要に応じて、ユーザースレッドはカーネルスレッドにマップし、独立したエンティティとしては実行できないシステムコールを発行できます。カーネルスレッドは、このシステムコールをカーネルにマップし、適切と思われる場合はアクションを実行します。
開発環境や言語によっては、機能のような独自のスレッドが追加されます。これは、環境に関する知識を活用するために書かれています。たとえば、GUI環境では、各イベントループでユーザースレッドを切り替えるスレッド機能を実装できます。ゲームライブラリには、キャラクターの行動のようなスレッドがあります。時々、ユーザースレッドのような振る舞いは別の方法で実装できます。たとえば、私は多くのココアを操作し、x秒ごとにコードを実行し、1秒の小数部を使用してスレッドのようにコードを実行するタイマーメカニズムを備えていますRubyは協調スレッドのようなyield機能を備えています。ユーザースレッドの利点は、より予測可能な時間に切り替えることができることです。カーネルスレッドでは、スレッドが再起動するたびに、作業中のデータ、これには時間がかかる可能性があり、ユーザースレッドを使用すると、一部のデータの作業が終了したときに切り替えることができるため、リロードする必要がありません。カーネルと同じように見えるユーザースレッドはありません。スレッド、タイマーなどのスレッドのようなメカニズムのみ、古いテキストの本でそれらについて読んだことがあるので、過去に人気があったが、真のマルチスレッドOS（現代のWindowsおよびMac OS X）の台頭であったかどうかより強力なハードウェアが好まれなくなったのではないかと思います。
ユーザースレッドとカーネルスレッドの違い
ユーザースレッド
- どのOSでも実行可能
- スレッド管理はスレッドライブラリによって行われます
- カーネルはスレッドの存在を認識していません
- スレッドライブラリには、スレッドを作成および破棄するためのコードが含まれています
- これらは、アプリケーションプログラマがプログラムで使用するスレッドです
カーネルスレッド
- OSに固有
- カーネルによって行われるスレッド管理
- アプリケーション領域にスレッド管理コードはありません
- オペレーティングシステムによって直接サポートされています
- プロセス内の1つのスレッドがブロックされている場合、カーネルは同じプロセスの別のスレッドをスケジュールできます。
- カーネルスレッドは通常、ユーザースレッドよりも作成と管理が遅い
ユーザースレッド：1.ライブラリは、カーネルのサポートなしでスレッドの作成、スケジューリング、および管理をサポートします。 2.ユーザーレベルのスレッドの作成とスケジューリングを認識しないカーネルは、カーネルの介入なしにユーザー空間で実行されます。 3.ユーザーレベルのスレッドは一般的に作成と管理が高速ですが、欠点があります。 4.カーネルがシングルスレッドの場合、ブロッキングシステムコールを実行するユーザーレベルのスレッドは、アプリケーション内で他のスレッドを実行できる場合でも、プロセス全体をブロックします。 5.ユーザースレッドライブラリには、POSIX Pthreads、Mach C-threads、およびSolaris 2 UI-threadsが含まれます。
カーネルスレッド：1.カーネルは、カーネル空間でスレッドの作成、スケジューリング、および管理を実行します。 2.一般に、カーネルスレッドは、ユーザースレッドよりも作成と管理が遅くなります。 3.スレッドがブロッキングシステムコールを実行する場合、カーネルはスレッドを管理しています。 4.マルチプロセッサ環境では、カーネルは異なるプロセッサでスレッドをスケジュールできます。 5. Windows NT、Windows 2000、Solaris 2、BeOS、およびTru64 UNIX（以前のDigital UN1X）を含むカーネルスレッドをサポートします。