シングルコア CPU の場合、スレッドを使用してコーディングするメリットは何ですか?
少なくとも Java の実装では、単一コアの制限を考慮すると、他の言語に自然に拡張するのは直感的に思えます。さまざまなアクションを実行する複数のスレッドが存在する可能性がありますが、プロセスは時間制限があり、切り替えられます。
プロセス A とプロセス B が与えられた場合:
プロセスAの半分を実行し、プロセスBを終了してからプロセスAの後半を終了するVSプロセスAを実行してからBを実行する利点は何ですか?
スレッド間の切り替えにより、時間の遅延が発生し、両方のプロセスの全体的な完了時間が長くなり、切り替えられず、A と B だけが完了するようです。
多くの理由があります。ウィキペディアは、スレッドに関するページでまともな概要を説明しています。
ここにいくつかのOTOHがあります：
あなたのプログラムが「同時に」いくつかのことをしなければならない場合、スレッドは良い方法です。特に、これらのタスクのいくつかは非常に長時間実行されます。そうしないと、プログラム内にオペレーティング システムのスケジューラのように見えるコードを書いていることに気付きます。その下にある OS がすでに完全に優れたものを持っている場合、これは常に時間の無駄です。ソース コードの大部分が「スケジューラ」であり、「プログラム」があまりないことがわかります。これは非常に洗練されていません。優れたスレッド化されたプログラムは、ソース コードが非常にエレガントで経済的であり、見栄えがよくなり、時間を節約できます。
一部の実行時間は間違っています。Ada の初期の頃は、ランタイム環境が独自のスレッド スケジューリングを行っていましたが、満足のいくものではありませんでした。これは、Ada の言語仕様にはスレッドの概念が含まれていましたが、当時の OS ではスレッドが提供されていないことが多かったためです。コンパイラの作成者が代わりに基盤となる OS スレッドを使用し始めたとき、Ada は大幅に改善されました。
同様に、Python は基盤となる OS スレッドを適切に使用していません。グローバルインタープリターロックでそれを台無しにします。Python は、代わりにマルチプロセッシングを採用することで、問題全体を回避しました (Windows ホストでは必ずしも良いことではありません...)。
Windows の初期のバージョンもスレッドを実行せず、協調的なマルチタスクを実行していました。これは、少なくとも時々 OS ルーチンを呼び出すマシン全体の各プロセスに依存していました。各 OS ルーチンは、最初に「スケジューラ」を参照して、プログラムに代わって行うべきことを実行する前に、実行を待機しているものがないかどうかを確認します。当時、ボールを動かさず、マシン全体を占有するひどいプログラムがたくさんありました。他の何かが長さの計算に着手したとき、ソリティアのゲームを続けることができませんでした。