問題タブ [context-switch]

特定の Win32 スレッドによる CPU 使用率を計算するために必要な 2 つのシステム コール GetSystemTime() と GetThreadTimes() があります。

正確を期すために、GetSystemTime() と GetThreadTimes() の両方がアトミックに実行されるようにする必要があります。つまり、GetSystemTime() と GetThreadTimes() の呼び出しの間にコンテキスト スイッチがあってはなりません。

その理由は、ときどき 100% を超えるパーセンテージ (~ 500 分の 1) になるからです。

2 つの関数呼び出しをアトミックに実行するにはどうすればよいですか?

ありがとう、サチン

私は（C＃で）作成しているプログラムを持っています.2つのアプローチがあります..

1) 任意の数の X スレッドが終了するのを待つジョブ マネージャー。終了すると次の作業チャンクを取得し、新しいスレッドを作成してそのチャンクを与えます。

また

2) 開始する X スレッドを作成し、それぞれに作業のチャンクを与えます。スレッドがチャンクを終了すると、ジョブ マネージャーに追加の作業を要求します。それ以上仕事がない場合は、スリープしてから再度質問し、スリープは次第に長くなります。

このプログラムは実行されて完了しますが、より多くの仕事を継続的に探すサービスに変わることがわかりました.

各チャンクは、いくつかのデータ ID、情報を取得するためのデータベースへの呼び出し、またはデータ ID に対する操作の実行、およびデータ ID に関するデータベース情報への書き込みで構成されます。

2 つのスレッド間のコンテキスト切り替えで正確に保存および復元されるもの

• 同じプロセスで
• 2 つのプロセス間

プログラムでスレッドに敏感な領域をテストしようとしていますが、gccが発行するすべての命令の後に呼び出しを強制的に挿入して、別のスレッドに手動で譲ることができる方法があるかどうか疑問に思っていました。

ありがとう、ロバート

わかりました..ここに問題の背景があります。ミューテックスで保護しようとしている「重要な」コードがいくつかあります。それはこのようなものになります

Mutex.Lock()

// 重要なコード // 一部のファイル IO

Mutex.Unlock()。

今の問題は、これが原因で私のプログラムが「スタック」しているように見えることです。例を挙げて説明しましょう。

Thread_1 が入ります。Mutex.Lock() に移動し、重要なコードの実行を開始します。重要なコードでは; ファイル IO を実行する必要があります。この時点で; 「コンテキスト切り替え」が発生し、Thread_2 が入って Mutex.Lock() でブロックされると思います (Thread_1 にロックがあるため)。すべて問題ないようですが、私の場合は。ここでプログラムが「ハング」します..私が考えることができる唯一のことは、どういうわけかThread_2が永遠にブロックし続け、Thread_1に戻らないということです??

詳細: Linux で pthread_mutex_init と pthread_mutex_lock を使用する。

Linuxでコンテキストスイッチに費やされた時間を見つけるためにacプログラムを書くことはできますか？コードをお持ちの場合は共有していただけますか？ありがとう

各スレッドが生成するコンテキスト スイッチの数を確認する方法はありますか? (可能であればインとアウトの両方) X/s で実行するか、実行してしばらくしてから集計データを取得します。（LinuxまたはWindowsのいずれか）

OS全体またはプロセスごとに集計されたコンテキスト切り替え数を提供するツールのみを見つけました。

私のプログラムは多くのコンテキスト切り替え (50k/s) を行いますが、おそらくそれほど多くは必要ありませんが、どこから最適化を開始すればよいのか、それらのほとんどがどこで行われるのかわかりません。

並行して実行する必要のあるタスクが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つ）で作成するのが最適です。

マルチスレッドのpthreadアプリケーションでのコンテキスト切り替えの動作を監視したいと思います。

他のRTOS（Micro C OS）では、アプリケーションのスレッドごとにコンテキストスイッチコールバックを登録し、ログに記録して（または、gpioを切り替えて）、スレッドコンテキストの切り替えをリアルタイムで監視することができました。これは、複数のスレッドのリアルタイムの動作と相互作用をデバッグするための貴重なツールでした。

私の現在の環境は、pthreadapiを利用した組み込みLinuxです。各コンテキストスイッチを監視する方法はありますか？

私は、C++ で Linux 上のスレッド化されたアプリケーションに取り組んでいます。これは、リアルタイムで、ハートビートで、または可能な限りそれに近いアクションを実行しようとします。

実際には、OS がスレッドをスワップアウトしていて、スレッドが切り替えられている間に最大 10 分の 1 秒の遅延が発生し、ハートビートが不規則になることがわかりました。

私のスレッドが OS に、コンテキストを切り替える良い時期であることを示唆する方法はありますか? ハートビートを実行した直後にこの呼び出しを行うことができたので、タイミングの悪いコンテキスト スイッチによる遅延を最小限に抑えることができました。