両方のコアを利用できる主流の最新のOSを備えたデュアルコアマシンがあるとします。同じプロセス内にP1とQ1の2つのスレッドがあり、それらがたまたま子スレッドの作成を開始した場合、たとえば、 P2とQ2は、ほぼ同じマシンサイクルで、OSはスレッドの作成を同時に実行しますか?
スレッドの作成には費用がかかると聞いたので、質問が出ました...
前もって感謝します。
両方のコアを利用できる主流の最新のOSを備えたデュアルコアマシンがあるとします。同じプロセス内にP1とQ1の2つのスレッドがあり、それらがたまたま子スレッドの作成を開始した場合、たとえば、 P2とQ2は、ほぼ同じマシンサイクルで、OSはスレッドの作成を同時に実行しますか?
スレッドの作成には費用がかかると聞いたので、質問が出ました...
前もって感謝します。
適切に設計された OS であれば、カーネル コードを同時に実行する複数のプロセッサを搭載できます。したがって、スレッドの作成に関連するタスクの一部は、同時に発生する可能性があります。ただし、一部の共有データ構造を操作するために必要なシリアライゼーションがあります (たとえば、メモリの割り当て、新しく作成された脅威構造のグローバル リストへの挿入など)。プロセッサは同じロックを求めて競合する可能性があり、それによって同時実行性が低下します。
スレッド作成のオーバーヘッドが実際に問題になるほど頻繁に新しいスレッドを作成するシステム/アプリケーションは、おそらく間違って設計されています (起動時間に比べてスレッドでの有用な作業が少なすぎ、寿命の短いスレッドを再利用するという明らかな最適化を利用していません)。プールから)。
同時進行になります。並行して進めることができないスレッド作成の側面があります - カーネルメモリマネージャーが両方のスレッドに同じスタックを割り当てた場合、残念です!
スレッドの作成は十分にコストがかかるため、アプリ中にスレッドを作成することはまったく避けても、それだけの価値はあります。したがって、スレッドプールの人気があります。ブロックする実行時間の長いタスクは、スレッド化してアプリの存続期間中そのままにしておくことができます。これは、多くの場合、明示的なスレッドの終了 (ユーザー コードからの、せいぜいぎこちなく、最悪の場合ほとんど不可能) が不要であることを意味します。
開発者は、スレッドを「関数」として考えたいため、スレッドを継続的に開始および停止すると思います。開始時に「パラメーターを渡し」、スレッドの終了時に結果を「返す」ものです。これは、スレッドを概念化する最良の方法ではありません。