並行して実行する必要のあるタスクが2つ（3つ、4つなど）あると想像してください。さて、これを行う簡単な方法は、別々のスレッドを作成してそれを忘れることです。しかし、昔ながらのシングルコアCPUでは、多くのコンテキストスイッチングを意味します。コンテキストスイッチングが大きく、悪く、遅く、一般的には単に悪であることは誰もが知っています。避けるべきですよね？
その点で、とにかくソフトウェアをゼロから作成している場合は、さらに一歩進んで、独自のタスク切り替えを実装することができます。各タスクを部分に分割し、その間の状態を保存してから、単一のスレッド内でタスクを切り替えます。または、複数のCPUコアがあることを検出した場合は、各タスクを別々のスレッドに渡すだけで、すべてうまくいくでしょう。
2番目のソリューションには、使用可能なCPUコアの数に適応できるという利点がありますが、手動のタスク切り替えは、OSコアのものよりも本当に高速ですか？TaskManager特に、全体をaやanITaskなどで一般的にしようとしている場合はどうでしょうか。
明確化：私はWindows開発者なので、主にこのOSの答えに興味がありますが、他のOSについても知ることが最も興味深いでしょう。答えを書くときは、それがどのOSであるかを述べてください。
さらに明確にする：わかりました。したがって、これは特定のアプリケーションのコンテキストではありません。これは本当に一般的な質問であり、スケーラビリティについての私の考えの結果です。アプリケーションを拡張して、将来のCPU（および現在のさまざまなCPU）を効果的に利用したい場合は、マルチスレッドにする必要があります。しかし、スレッドはいくつですか？一定数のスレッドを作成すると、プログラムは、同じ数のコアを持たないすべてのCPUで最適に実行されません。
スレッドの数は実行時に決定されるのが理想的ですが、実行時に任意の数の部分に実際に分割できるタスクはほとんどありません。ただし、多くのタスクは、設計時にかなり大きな一定数のスレッドに分割できます。したがって、たとえば、私のプログラムが32スレッドを生成できる場合、それはすでに最大32コアのCPUのすべてのコアを利用しますが、これはまだかなり先のことです（私は思います）。しかし、単純なシングルコアまたはデュアルコアCPUでは、コンテキストスイッチングが大量に発生するため、処理速度が低下します。
したがって、手動タスク切り替えについての私の考え。このようにして、32個の「仮想」スレッドを作成し、それを最適な数の実際のスレッドにマップし、「コンテキスト切り替え」を手動で行うことができます。問題は、手動の「コンテキスト切り替え」のオーバーヘッドは、OSコンテキスト切り替えのオーバーヘッドよりも少ないのでしょうか。
当然、これはすべて、ゲームのようにCPUにバインドされたプロセスに適用されます。ありふれたCRUDアプリケーションの場合、これはほとんど価値がありません。このようなアプリケーションは、1つのスレッド（最大2つ）で作成するのが最適です。