問題タブ [context-switch]

プロファイラーを使用せずにコンテキスト スイッチがいつ発生するかを判断する方法はありますか? プログラム内のさまざまなプロセスが実行を完了するのにかかる時間を監視する C プログラムを作成しました。プロセス/スレッド コンテキストの切り替えも示したいと思います。切り替えが行われる時刻とprev_id -> curr_id. この3つの情報は役に立ちます。

両方の状況で正確に何が行われるか教えてもらえますか? それぞれの主な費用はいくらですか？

私が大学で取ったコースで覚えているのは、競合状態の私のお気に入りの例の 1 つは、単純なmain()メソッドが 2 つのスレッドを開始し、そのうちの 1 つは共有 (グローバル) 変数を 1 ずつインクリメントし、もう 1 つはそれをデクリメントするというものでした。擬似コード:

次に、教授はi、100 万億回実行した後の の値を尋ねました。(本質的に 10 以外になるとしたら。) マルチスレッド システムに慣れていない学生は、100% の確率で、このprint()ステートメントは常にi10 と報告されると答えました。

私たちの教授は、各インクリメント/デクリメント ステートメントが実際には 3 つのステートメントとして (アセンブリに) コンパイルされたことを示したため、これは実際には正しくありません。

したがって、 の値はi9、10、または 11 になる可能性があります (詳細には触れません)。

私の質問：

物理レジスタのセットがプロセッサ固有であることは、私の理解でした（そうですか？）。デュアル CPU マシンで作業する場合 (デュアルコアとデュアル CPU の違いに注意してください)、各 CPU には独自の物理レジスタ セットがありますか? 私は答えがイエスだと思っていました。

シングル CPU (マルチスレッド) マシンでは、コンテキスト切り替えにより、各スレッドが独自の仮想レジスタ セットを持つことができます。デュアル CPU マシンには 2 つの物理的なレジスタ セットがあるため、競合状態が発生する可能性がさらに高まるのではないでしょうか。 CPUマシン？(コンテキストスイッチごとにレジスタの状態を退避・復帰することを参考にした仮想同時動作。)

より具体的に言えば、これを 8 CPU マシンで実行した場合、各 CPU に 1 つのスレッドがあり、競合状態は解消されますか? この例を拡張して、各 CPU に 4 つのコアを持つデュアル CPU マシンで 8 つのスレッドを使用する場合、競合状態の可能性は増加しますか、それとも減少しますか? オペレーティング システムは、アセンブリ命令が 2 つの異なる CPU で同時に実行されるのをどのように防いでいますか?step 3

「エージェント」クラスを持つC＃プログラムがあります。このプログラムは複数のエージェントを作成し、各エージェントには「run()」メソッドがあり、タスクを実行します (つまり、Task.Factory.StartNew() ...)。
各エージェントはいくつかの計算を実行し、次の段階に進む前に、他のすべてのエージェントが計算を完了するのを待つ必要があります (彼のアクションは、他のエージェントの計算に基づいています)。
Agent を待機させるために、CancellationTokenSource (「tokenSource」という名前) を作成し、この Agent がスリープ状態になることをプログラムに警告するために、イベントをスローしました。したがって、2 つの連続するコマンドは次のとおりです。

(イベントは、それ自体がスレッドである「AgentManager」クラスによってキャッチされます。2 番目のコマンドは、キャンセル トークンのシグナルが受信されるまで、エージェント タスク スレッドをスリープ状態にします)。

上記のイベントが発生するたびに、AgentManager クラスがそれをキャッチし、カウンターに +1 を追加します。カウンターの数がプログラムで使用されるエージェントの数と等しい場合、AgentManager (すべてのエージェントへの参照を保持する) は、次のように各エージェントを起動します。

ここで私の問題に到達します。最初のコマンドはエージェントによって非同期的に実行され、スレッド間のコンテキストの切り替えにより、AgentManager がイベントをキャッチしたように見え、すべてのエージェントを起動します。しかし - 現在のエージェントはまだ 2 番目のコマンドに到達していません。このように、エージェントは「起床」信号を受信し、それから初めて眠りにつくことになります。2 つの連続するメソッドをまとめて「原子化」する方法はありますか? そのため、コンテキストの切り替えは発生せず、AgentManager が彼を起こす前にエージェントを強制的にスリープ状態にしますか?

スレッドハンドルまたはスレッドIDがあると仮定して、C ++のコンテキストスイッチを特定のスレッドに強制する方法はありますか？

プロセスが多くのコンテキスト スイッチを引き起こす場合、コンテキスト スイッチで使用された CPU サイクルはプロセスの CPU 使用率に表示されますか?
つまり、基本的にシステム コールを繰り返し実行するプロセスを実行する場合、ユーザー空間からカーネル空間へ、またはその逆のコンテキスト切り替えが増加するため、topの出力はプロセスの CPU 使用率の増加を示す必要がありますか?

Linux 上の同じプロセスのスレッド間のコンテキスト切り替えのコストに関する適切な経験的データはありますか (主に x86 と x86_64 が重要です)。私は、あるスレッドがユーザー空間で実行する最後の命令と、自発的または非自発的にスリープ状態になる前のサイクル数またはナノ秒数と、同じ cpu/コアでウェイクアップした後に同じプロセスの別のスレッドが実行する最初の命令について話している.

同じ CPU/コアに割り当てられた 2 つのスレッドで常に実行rdtscし、結果を volatile 変数に格納し、姉妹スレッドの対応する volatile 変数と比較する簡単なテスト プログラムを作成しました。姉妹スレッドの値の変更を初めて検出すると、違いが出力され、ループに戻ります。この方法で、Atom D510 CPU で約 8900/9600 サイクルの最小/中央値を取得しています。この手順は合理的で、数字は信頼できると思いますか?

私の目標は、最新のシステムで、接続ごとのスレッド サーバー モデルが選択型の多重化と競合するか、それを上回るかどうかを見積もることです。Xfd で IO を実行することから fd への移行Yは、複数のシステムコールではなく、あるスレッドでスリープ状態になり、別のスレッドで起動するだけであるため、理論的にはもっともらしいようですが、コンテキスト切り替えのオーバーヘッドに依存します。

MauriceBachのTheDesignof the Unix Operating Systemには、作成中にコンテキストスイッチが原因で二重リンクリストが破棄される可能性があることを示す例があります。（彼は、このような重要なコード領域でプロセッサレベルを上げることでこれを防ぐことができると言い続けていますが、そもそも問題を示しようとする彼の推論を理解するのに苦労しています）彼に含まれるサンプルコードは次のとおりです。次のとおりです。

彼が書いた図は最初に示しています：

次に、最終状態を表示するには：

ロジックをウォークスルーしようとしていますが、コードが示されているように二重リンクリストが壊れてしまう理由がわかりません。誰かがこの問題を引き起こすためにコンテキストスイッチ中に何が起こっているのか説明できますか？

（psは二重リンクリストとしてタグ付けされますが、タグ作成権限はありません）

XML 用の Zend のデフォルトの ContextSwitch Action Helper は、Content-Type ヘッダーを誤って「application/xml」に設定しますが、ドキュメントでは「test/xml」に設定すると主張しています。

他の誰かがこれにぶつかりましたか。バグですか？ありがとう。

zend アクションヘルパーのドキュメント

みんな。私は同様のことでスタックしています:私はZend Frameworkでダウンロードファイル機能を提供する必要があります...数時間のグーグル検索はこれで私を助けません...だからここに私のコントローラーコードがあります(注:私は初心者です):

PS: このダウンロード ファイルは zend フレームワークで見つかりましたが、この Zend の方法で実行したいと考えています。皆さん、ありがとうございました