高同時実行におけるスレッドとスレッドプールの詳細な説明

すべてはCPUから始まります

マルチスレッドについて話すときに、なぜ CPU から始めるのかと疑問に思われるかもしれません。理由は簡単で、流行の概念が存在せず、問題の本質がより明確に見えるからです。CPU はスレッドやプロセスなどの概念を知りません。CPU は次の 2 つのことだけを知っています: 1. メモリから命令をフェッチする 2. 命令を実行して 1 に戻る

ご存知のとおり、ここでは CPU はプロセスとスレッドの概念を実際には認識していません。次の疑問は、CPU がどこから命令をフェッチするのかということです。答えは、よく知られているプログラムカウンタであるプログラムカウンタ（以下PC）というレジスタです。ここではレジスタをあまり難しく考えず、単純にメモリとして理解していただければ良いのですが、アクセス速度はただ速くなります。PCレジスタには何が保存されますか? ここに保存されているのはメモリ内の命令のアドレスですが、どの命令ですか? CPU が次に実行する命令です。

では、誰が PC レジスタに命令アドレスを設定するのでしょうか? PC レジスタのアドレスはデフォルトで自動的に 1 ずつインクリメントされることがわかりましたが、これは当然のことです。ほとんどの場合、CPU は 1 つずつ順番に実行するためです。if と else が発生すると、この順番の実行は中断されます。 CPU がこの種の命令を実行すると、計算結果に応じて PC レジスタの値が動的に変更されるため、CPU は実行する必要のある命令に正しくジャンプできます。PC の初期値はどのように設定されているのですか? この質問に答える前に、CPU によって実行される命令がどこから来たのかを知る必要があります。それはメモリから来ます、ナンセンスです、メモリ内の命令はディスクに保存された実行可能プログラムからロードされます、ディスク内の実行可能プログラムはコンパイラによって生成されます、そしてコンパイラはどこで機械語命令を生成しますか？答えは私たちが定義した関数です。

これは関数であることに注意してください。関数がコンパイルされると、CPU によって実行される命令が形成されます。では当然、CPU に関数を実行させるにはどうすればよいでしょうか? 明らかに、関数のコンパイル後に形成された最初の命令を見つける必要があるだけであり、最初の命令は関数のエントリです。ここで、CPU に関数を実行させたいことがわかりました。その関数に対応する最初の機械語命令のアドレスを PC レジスタに書き込むだけで、記述した関数が CPU によって実行され始めます。。これはスレッドとどのような関係があるのでしょうか?という疑問があるかもしれません。

CPUからOSまで

前のセクションでは、CPU の動作原理を理解しました。CPU に特定の機能を実行させたい場合、その機能に対応する最初のマシン実行を PC レジスタにロードするだけで済みます。オペレーティングシステムがなくても関数を実行する CPU 実行プログラムは実行可能ですが、これは非常に面倒なプロセスです。

メモリ内で適切なサイズの領域ローダーを見つける
関数エントリを見つけて、PC レジスタを設定し、CPU にプログラムの実行を開始させます。

この 2 つのステップは決して簡単ではありませんが、プログラムを実行するたびに上記 2 つの処理を手動で実装すると頭がおかしくなってしまいますので、賢いプログラマであれば、上記 2 つのステップを自動的に完了するプログラムを簡単に作成したいと考えます。ステップ。

機械語命令は実行のためにメモリにロードする必要があるため、メモリの開始アドレスと長さを記録する必要があり、同時に関数のエントリアドレスを見つけて PC レジスタに書き込む必要があります。この情報を記録するにはデータ構造が必要です。

struct *** {
   void* start_addr;
   int len;
   
   void* start_point;
   ...
};

続いては名付けの時間です。このデータ構造には常に名前が必要です。この構造はどのような情報を記録するために使用されますか? 記録されるのは、プログラムがメモリにロードされたときの実行状態です。ディスクからメモリにロードされたときのプログラムの名前は何ですか? それをプロセスと呼んでください。私たちの基本原則は、神秘的に聞こえなければならないということです。つまり、誰にとっても理解するのは簡単ではありません。私はそれを「理解できない原則」と呼んでいます。そしてそのプロセスが生まれました。CPU によって実行される最初の関数にも名前があり、最初に実行される関数の方が重要に思えるので、単にmain 関数と呼ぶことにします。上記の 2 つのステップを完了するプログラムにも名前を付ける必要がありますが、「原理が理解されていない」によれば、この「単純な」プログラムはオペレーティングシステム(Operating System) と呼ばれます。このようにしてオペレーティングシステムが誕生し、プログラマーはプログラムを実行する場合に手動でオペレーティングシステムを再度ロードする必要がなくなりました。プロセスと OS が配置されたので、すべてが完璧に見えます。

シングルコアからマルチコアへ、マルチコアを使いこなすには

人間の特徴の一つは、人生がシングルコアからマルチコアへと常に揺れ動いていることです。

このとき、プログラムを書いてマルチコアを使いたい場合はどうすればよいでしょうか？学生の中には、プロセスが存在しないので、さらにいくつかのプロセスを開くだけで十分だと言う人もいるかもしれません。それは合理的に思えますが、いくつかの問題があります。

プロセスはメモリ空間を占有する必要があります (前の省電力の説明を参照)。複数のプロセスが同じ実行可能プログラムに基づいている場合、これらのプロセスのメモリ領域の内容はほぼ同一となり、明らかにメモリの無駄が発生します。
コンピュータによって処理されるタスクは、プロセス間通信を伴うため、より複雑になる場合があります。各プロセスは異なるメモリアドレス空間にあるため、プロセス間通信には当然オペレーティングシステムの助けが必要となり、プログラミングやプログラミングの難易度が高まります。システムの複雑さが増大します。

それについて私たちは何ができるでしょうか？

プロセスからスレッドへ

この問題をもう一度よく考えてみましょう. いわゆるプロセスは、CPU によって実行される機械語命令と関数の実行時のスタック情報を格納するメモリの一部にすぎません. プロセスを実行するには、 main 関数最初の機械命令のアドレスが PC レジスタに書き込まれ、プロセスが実行を開始します。

プロセスの欠点は、エントリ関数、つまりメイン関数が 1 つだけであるため、プロセス内の機械語命令は1 つの CPU でしか実行できないことです。したがって、複数の CPU で機械語命令を実行する方法はありますか?同じプロセスですか？main 関数の最初の命令のアドレスを PC レジスタに書き込むことができるので、他の関数と main 関数の違いは何なのかを考えることができるはずです。答えは、違いはありません。 main 関数の特別な特徴は、それが CPU によって実行される最初の関数であるということです。それについて特別なことは何もありません。PC レジスタを main 関数にポイントすることができ、そして、次のことを行うことができますPC を任意の機能に登録します。PC レジスタがメイン関数以外を指すようにすると、スレッドが生成されます。

プロセスには複数のエントリ関数が存在する可能性があり、これは、同じプロセスに属する機械語命令が複数の CPU によって同時に実行される可能性があることを意味します。これはプロセスとは異なる概念であることに注意してください。プロセスを作成するときは、プロセスをロードするためにメモリ内の適切な領域を見つけてから、CPU の PC レジスタを main 関数にポイントする必要があります。つまり、実行は 1 回だけです。プロセスの流れを説明します。

しかし、現在は異なります。複数の CPU が、同じ屋根 (プロセスが占有するメモリ領域) の下で、プロセスに属する複数のエントリ関数を同時に実行できます。つまり、1 つのプロセス内に複数の実行フローが存在できるようになりました。。

いつも実行フローと呼ぶのはちょっと分かりやすすぎるので、またしても「原理が分からない」を犠牲にして、分かりにくい名前を付けてスレッドと呼びましょう。ここでスレッドの出番です。オペレーティングシステムはプロセスごとに、プロセスのメモリ空間などを記録するために使用される一連の情報を保持しており、この一連の情報はデータセット A として記録されます。同様に、オペレーティングシステムも、スレッドのエントリ関数やスタック情報を記録するために使用されるスレッドの大量の情報を維持する必要があり、このデータの山はデータセット B として記録されます。明らかに、データセット B の量はデータ A よりも少ないです。同時に、スレッドはアドレス空間で実行されるため、プロセスと異なり、スレッドを作成するときにメモリ内にメモリ空間を見つける必要はありません。このアドレス空間はプログラム内にあり、起動時に作成され、スレッドはプログラムの実行中 (プロセスの開始後) に作成されるため、スレッドが実行を開始すると、このアドレスがスペースはすでに存在しており、スレッドを直接使用できます。さまざまな教科書で取り上げられているスレッドの作成がプロセスの作成よりも速いのはこのためです (もちろん他の理由もあります)。スレッドの概念では、プロセスの開始後に複数のスレッドを作成するだけですべての CPU をビジー状態に保つことができ、これがいわゆる高パフォーマンスと高同時実行性の根源であることに注意してください。

非常に簡単で、適切な数のスレッドを作成するだけです。もう 1 つの注目すべき点は、各スレッドがプロセスのメモリアドレス空間を共有するため、スレッド間の通信がオペレーティングシステムに依存する必要がなく、プログラマにとっては非常に便利であり、トラブルが絶えないということです。スレッド間通信は便利すぎるため、エラーが非常に発生しやすいという事実があります。エラーの根本は、CPU が命令を実行するときにスレッドの概念を持たないことです。マルチスレッドプログラミングが直面する相互排除と同期の問題は、プログラマー自身が解決する必要があります。詳細な説明があります。最後に思い出していただきたいのは、スレッドの使用法を説明する前の図では複数の CPU が使用されていますが、複数のスレッドを使用するために複数のコアを使用する必要があるという意味ではありません。単一コアの場合は、複数のスレッドを使用することもできます。その理由は、スレッドはオペレーティングシステムレベルで実装されており、コアの数とは関係がありません。CPU が機械語命令を実行するとき、実行された機械語命令がどのスレッドに属しているかを認識しません。。CPU が 1 つしかない場合でも、オペレーティングシステムは、スレッドスケジューリングを通じて各スレッドを「同時に」進めることができます。「実行」しますが、実際には、常に 1 つのスレッドだけが実行されます。

電車による情報: Linux カーネルソースコード技術学習ルート + ビデオチュートリアルカーネルソースコード

電車で学ぶ: Linux カーネルソースコードメモリチューニングファイルシステムプロセス管理デバイスドライバー/ネットワークプロトコルスタック

スレッドとメモリ

前の説明で、スレッドと CPU の関係はわかりました。つまり、スレッドが実行できるように、CPU の PC レジスタがスレッドのエントリ関数を指すようにする必要があります。そのため、作成時にエントリ関数を指定する必要があります。スレッド。使用するプログラミング言語に関係なく、スレッドの作成方法はほぼ同じです。

// 设置线程入口函数DoSomething
thread = CreateThread(DoSomething);

// 让线程运行起来
thread.Run();

では、スレッドとメモリにはどのような関係があるのでしょうか? 関数が実行されたときに生成されるデータには、関数のパラメータ、ローカル変数、戻りアドレスなどの情報が含まれていることがわかっており、これらの情報はスタックに格納されます。スレッドという概念がまだ登場していない時点では、実行フローは 1 つだけです。プロセスなのでスタックは 1 つだけあり、スタックの一番下はプロセスのエントリ関数、つまり main 関数です。図に示すように、main 関数が funA を呼び出し、funcA が funcB を呼び出すとします。

では、スレッドを立てた後はどうでしょうか？スレッドを作成した後、プロセス内に複数の実行エントリが存在します。つまり、同時に複数の実行フローが存在します。その場合、実行フローが 1 つだけのプロセスには、ランタイム情報を保存するためにスタックが必要です。各実行フローの情報を保存するために複数のスタックが使用されます。つまり、オペレーティングシステムは、プロセスのアドレス空間内の各スレッドにスタックを割り当てる必要があります。つまり、各スレッドは独自のスタックを持ちます。これを認識することは非常に重要です。

同時に、スレッドの作成によりプロセスメモリ領域が消費されることもわかりますが、これも注目に値します。

糸の使用

スレッドの概念がわかったところで、次はプログラマとしてスレッドをどのように使用すればよいでしょうか? ライフサイクルの観点から見ると、スレッドで処理されるタスクには、長いタスクと短いタスクの 2 種類があります。1. 長いタスク、長生きするタスクは、名前が示すように、タスクが長期間存続することを意味します。たとえば、私たちがよく使う単語を例に挙げると、単語で編集したテキストはディスクに保存する必要があります。 , そして、データをディスクに書き込むのはタスクです。この時点でより良い方法は、ディスクに書き込むためのスレッドを作成することです。書き込みスレッドのライフサイクルはワードプロセスのライフサイクルと同じです。 Word が開かれると書き込みスレッドが作成され、ユーザーが Word を閉じるとスレッドが破棄されます。これは長いタスクです。

このシナリオは、比較的単純な特定のタスクを処理する専用スレッドを作成する場合に非常に適しています。長いタスクと、それに応じて短いタスクがあります。

2. 短いタスク。存続期間の短いタスクの概念も非常に単純です。つまり、ネットワークリクエスト、データベースクエリなど、タスクの処理時間が非常に短く、そのようなタスクはすぐに処理して完了できます。短い時間で。したがって、Web サーバー、データベースサーバー、ファイルサーバー、メールサーバーなどのさまざまなサーバーで短いタスクがより一般的であり、これはインターネット業界の学生にとって最も一般的なシナリオでもあり、私たちが注目したいのはこのシナリオです。。このシナリオには、タスクの処理時間が短いことと、タスクの数が膨大であることの 2 つの特徴があります。もしあなたがこの種の仕事を任されたらどうしますか？これは非常に単純で、サーバーがリクエストを受信すると、タスクを処理するスレッドを作成し、処理が完了した後にスレッドを破棄するだけなので、とても簡単だと思うかもしれません。このメソッドは通常、スレッドごとのリクエストと呼ばれます。これは、リクエストに対してスレッドが作成されることを意味します。

長いタスクの場合、この方法は非常にうまく機能しますが、多数の短いタスクの場合、この方法は実装が簡単ですが、いくつかの欠点があります。 1. 前のセクションからわかるように、スレッドはオペレーティングシステムの一部という概念 (ユーザーモードスレッド、コルーチンなどの実装についてはここでは説明しません) であるため、スレッドの作成は当然オペレーティングシステムの助けを借りて完了する必要があり、 2. 各スレッドは独自の独立したスタックを持つ必要があるため、多数のスレッドが作成されると、メモリやその他のシステムリソースが過剰に消費されます。これは工場のオーナーのようなものです。 (考えてみてください、あなたは幸せですか?) そして、あなたはたくさんの注文を持っています。注文のバッチが届くたびに、労働者のバッチを雇う必要があります。生産される製品は非常にシンプルで、労働者は迅速に処理してください。この一連の注文を処理した後、採用に熱心に取り組んでいた労働者は解雇されます。新しい注文が入ったら、一生懸命採用します。労働者は 1 回、5 分間働き、10 分間人材を採用します。会社を倒産させたくなければ、おそらく倒産させないでしょう。したがって、より良い戦略は、グループで人材を採用し、その場で人材を育てることです。命令はなく、命令がないときは誰もが何もせずに過ごすことができます。

これがスレッドプールの起源です。

マルチスレッドからスレッドプールへ

スレッドプールの概念は非常に単純です。スレッドのバッチを作成し、その後それらを解放しないだけです。タスクは処理のためにこれらのスレッドに送信されるため、スレッドを頻繁に作成および破棄する必要はありません。同時に、スレッドプール内のスレッドの数により、通常は固定されており、あまり多くのメモリを消費しないため、ここでのアイデアは、を再利用して制御可能にすることです。

スレッドプールの仕組み

学生の中には、タスクをスレッドプールに送信するにはどうすればよいのかと疑問に思う人もいるかもしれません。これらのタスクはスレッドプール内のスレッドにどのように与えられるのでしょうか? 明らかに、データ構造内のキューはこのシナリオに自然に適しています。タスクを送信するプロデューサーはプロデューサーであり、タスクを消費するスレッドはコンシューマーです。実際、これは古典的なプロデューサーとコンシューマーの問題です。

これで、オペレーティングシステムのコースが教えられ、面接でこの質問が行われる理由がわかるはずです。プロデューサーとコンシューマーの問題を理解していなければ、基本的にスレッドプールを正しく書くことができないからです。スペースの制限のため、ブロガーはここで生産者と消費者の問題について詳しく説明するつもりはありません。答えはオペレーティングシステムの関連情報を参照することで得られます。ここでブロガーは、スレッドプールに送信されるタスクが一般的にどのようなものであるかについて話すつもりです。一般に、スレッドプールに送信されるタスクは、1) 処理されるデータ、2) データを処理する関数の2 つの部分で構成されます。

struct task {
void* data;     // 任务所携带的数据
    handler handle; // 处理数据的方法
}

(コード内の構造体をクラス、つまりオブジェクトとして理解することもできます。) スレッドプール内のスレッドはキュー上でブロックされます。プロデューサーがデータをキューに書き込むと、スレッドプール内のスレッドがキューにブロックされます。目覚めた後、スレッドはキューから上記の構造体 (またはオブジェクト) を取り出し、構造体 (またはオブジェクト) 内のデータをパラメーターとして受け取り、処理関数を呼び出します。

while(true) {  struct task = GetFromQueue(); // 从队列中取出数据  task->handle(task->data);     // 处理数据}

上記はスレッドプールのコア部分です。これらを理解すると、スレッドプールがどのように機能するかを理解できます。

スレッドプール内のスレッドの数

スレッドプールがあるので、スレッドプール内のスレッドの数はいくつでしょうか? 次に進む前に、これについて自分で考えてください。これが見えたらまだ寝ていません。スレッドプール内のスレッドが少なすぎると CPU を最大限に活用できず、作成されるスレッドが多すぎると、システムパフォーマンスの低下、過剰なメモリ使用、スレッドの切り替えによる消費などが発生することを知っておく必要があります。したがって、スレッド数は多すぎても少なすぎてもいけませんが、どのくらいにすればよいのでしょうか。この質問に答えるには、スレッドプールが処理するタスクの種類を知る必要がありますが、学生の中には 2 種類あると答えた人もいるかもしれません。長いタスクと短いタスク、これはライフサイクルの観点からの話なので、タスクを処理するために必要なリソースの観点からも 2 つのタイプがあり、何も探す必要がなく抽象的です。。ああ、いいえ、CPU と I/O を集中的に使用します。1. CPU 集中型いわゆる CPU 集中型とは、処理タスクが科学計算や行列演算などの外部 I/O に依存する必要がないことを意味します。この場合、スレッド数とコア数が基本的に同じであれば、CPU リソースを最大限に活用できます。

2. I/O 集中型のタスクでは、計算部分にはそれほど時間がかからず、ほとんどの時間がディスク I/O やネットワーク I/O などに費やされます。

この場合、少し複雑になります。パフォーマンステストツールを使用して、I/O 待機に費やされた時間を評価する必要があります。ここでは WT (待機時間) として記録され、CPU の計算に必要な時間はここに記録されます。 CT (計算時間) とすると、N コアシステムの場合、I/O 待機時間が計算時間と同じであると仮定すると、適切なスレッド数はおそらく N * (1 + WT/CT) になります。 CPU リソースを完全に活用するには約 2N スレッドが必要ですが、これは理論上の値にすぎず、実際のビジネスシナリオに従って特定の設定をテストする必要があることに注意してください。もちろん、考慮する必要があるのは CPU を最大限に活用することだけではなく、スレッド数が増加するにつれて、メモリ使用量、システムスケジューリング、開いているファイルの数、開いているソケットの数、開いているデータベースリンクのすべてが考慮されるようになります。考慮する必要があります。したがって、ここに普遍的な公式はなく、ケースバイケースで分析する必要があります。

スレッドプールは万能薬ではありません

スレッドプールはマルチスレッドの一種にすぎないため、デッドロックの問題や競合状態の問題など、マルチスレッドが直面する問題も避けられません。この部分については、オペレーティングシステムの関連情報も参照できます。答えを導き出すシステムですから、基礎がとても重要なのです、オールドアイアン。

スレッドプールの使用に関するベストプラクティス

スレッドプールはプログラマにとって強力な武器です。スレッドプールはインターネット企業のほぼすべてのサーバーで見られます。スレッドプールを使用する前に、次のことを考慮する必要があります。

タスクが長いタスクか短いタスクか、CPU 集中型か I/O 集中型かにかかわらず、タスクを完全に理解します。両方がある場合は、これら 2 種類のタスクを別のスレッドに配置することをお勧めします。プール、これはスレッド数を決定するより良い方法かもしれません
スレッドプール内のタスクに I/O 操作がある場合は、必ずこのタスクにタイムアウトを設定してください。そうしないと、タスクを処理するスレッドが永久にブロックされる可能性があります。
スレッドプール内の他のタスクの結果を同期的に待たないことをお勧めします。

要約する

このセクションでは、CPU から始まり、一般的に使用されるスレッドプールに至るまで、下位層から上位層まで、ハードウェアからソフトウェアまで説明します。この記事には特定のプログラミング言語がないことに注意してください。スレッドは言語レベルの概念ではありません (ユーザーモードスレッドはまだ考慮されていません)。しかし、スレッドを本当に理解すれば、どの言語でも多くのスレッドを使用できると思います。理解する必要があるのはタオであり、その先に芸術があるのです。この記事がスレッドとスレッドプールの理解に役立つことを願っています。

原作者：コードファーマーの無人島サバイバル