シングルコアプロセッサでのシングルスレッドプログラミングとマルチスレッドプログラミング
誰かが、単一のコアを備えた単一のプロセッサで実行されるマルチスレッドのコードを書くことに本当に利点があるかどうかを説明できますか？例えば、ページが前述のコードの一部と相互に排他的であるようにドキュメントページを処理する方法。
一見すると、真のマルチスレッド化は不可能であるため、利点はないように思われます。つまり、OSはとにかくスレッドをコンテキストスイッチする必要があります。シングルスレッドで何かをコーディングするだけで、実際にはもっと効率的になるのではないかと思います。
明らかに、マルチスレッドコードを書くことが理にかなっている場合はたくさんありますが、アプリケーションがシングルコアプロセッサで実行されているときにそうすることの利点が本当にあるかどうかという質問があります。
編集：「アプリケーション」ではなく「コードの一部」と言ったことに注意してください-上記の例を見てください。明らかに、マルチスレッドアプリケーションを持つことには利点があります。
まだ得られる利点はありますが、状況は少し異なります。
多くの場合、Thingに複数のスレッドを与えると、他のプロセスからより多くのシステムリソースを要求できるようになります。これはバランスを取るのが難しいです。導入する各スレッドは少しオーバーヘッドを追加しますが、それが理由になる可能性があります。
ファイルIOやGUIインタラクションなど、ブロックする可能性のある複数のリソースを処理している場合は、マルチスレッドが不可欠になる可能性があります。
はい、マルチスレッドはシングルコアで役立ちます。アプリケーションの1つのスレッドが何かを待って（たとえば、ネットワークカードからのデータを待っている、またはディスクがデータを書き込むのを待っている）ブロックされた場合、CPUは別のスレッドに切り替えて動作を続けることができます。
BeOSは、シングルコアプロセッサの時代でも、普及したマルチスレッドを念頭に置いて作成されました。その結果、非常に応答性の高いOSになりましたが、プログラミングがかなり難しいOSでした。
シングルコアプロセッサでは、非同期（非ブロッキング）I/Oを使用するアプリケーションは、スレッド間のコンテキスト切り替えのオーバーヘッドを回避するため、複数のブロッキングスレッドを使用するアプリケーションよりもわずかに効率的です。
また、非同期I/Oは、新しいスレッドを作成するオーバーヘッドと比較して、追加のI/O操作ごとのオーバーヘッドが最小限であるため、スレッドでI/Oをブロックするよりも拡張性が高くなります。
そうは言っても、ほとんどすべての新しいプロセッサはマルチコアであるため、新しいアプリケーションでは通常、シングルスレッドの非同期I/Oを使用するべきではありません。代わりに、非同期I/Oを使用する必要がありますが、スレッドプールなどを使用して一連のワーカースレッド間で作業を分割します。システムドキュメントには、ワーカースレッドの理想的な数が記載されています。通常、使用可能なプロセッシングコアの数と同じです。
編集：少なくともWindowsプラットフォームでは、 。NETのasync/awaitパターン は非同期I/Oを実行する最新の方法です。これにより、このパターンは、古いブロッキングI/Oパターンと同じくらい簡単に記述できます。現在、ブロッキングI/Oを作成する言い訳はほとんどありません。