問題タブ [critical-section]

異なるクラス階層の 2 つのクラス間で同じクリティカル セクション オブジェクトを共有するという問題に対して、適切な設計ソリューションを見つけるのに苦労しています。

想像：

これで、method_one() と method_two() の呼び出しが同期されます。たまたま同期に critical_section オブジェクトを使用しているのですが、どうすればよいのでしょうか。

私はいくつかのアイデアを理解することができました：

1. 悪いcritical_section m_cs;- A または B のいずれかの適切なメンバー ( ) を作成し、
   a) IA から A (または IB から B にそれぞれ) にダウンキャストし、それを使用します
   b) 静的にし、呼び出しますA::m_cs(またはB::m_cs)

2. BETTER - critical_section オブジェクトを管理し、それへのアクセスを提供する追加のシングルトン オブジェクト/構造体を作成します。

   /li>

残念ながら、私はこれらのどれにも満足しておらず、誰かがより良いアイデアを持っていると思います.

この場合、2 つのクラス間で単一のクリティカル セクションを共有する方法は?

今日私はMSDNでこれに出くわしました：

他のスレッドが続行する準備ができていることを通知するために使用するスレッドごとに1つ。コンシューマースレッドは、プロデューサーがイベントを通知するのを待ってからクリティカルセクションに入り、プロデューサースレッドは、コンシューマースレッドがイベントを通知するのを待ってからクリティカルセクションに入る。各スレッドがクリティカルセクションを離れた後、他のスレッドを解放するようにイベントに通知します。」

最初はWTFと思いました！-私は常に、スレッドがクリティカルセクションを取得しようとした順序で取得することを想定していました。これはServicePackの動作に奇妙な大きな変化があるように見えますが、ServicePackはWindowsのServerEdition用であり、Vistaは当時開発中でした。

とにかく、それは少し意味があります-このように、スケジューラーが回転する次の待機中のスレッドは、少なくとも次のクリティカルセクションを取得するスレッドになると思います。したがって、彼らが楽しみのためにランダムな選択をすることに決めない限り、それが理にかなっている唯一のことです;）。

それでも、これは私が行った仮定であり、現在、FIFO依存のケースが問題にならないことを確認するためにコードを評価しています。

誰かがこれに関して現実の問題を抱えていましたか？クリティカルセクションを取得するスレッドの順序はFIFOであることが保証されていませんが、通常はFIFOではありませんか？通常はFIFO（またはFIFOに近い）ではない場合、スレッドが激しく争われているクリティカルセクションを待機できる時間を知っている人はいますか？優先度の低いスレッドの場合、クリティカルセクションを取得しようとする優先度の高いスレッドが常に存在する場合（FIFOが順守されていれば、優先度の低いスレッドがずっと前に並んでいたとしても）、ほぼ無期限に待機し続ける可能性があります。 ）？このシナリオを防ぐための安全上の問題はありますか、それともセカンダリ同期オブジェクトへの依存が義務付けられていますか？

もちろん、これは本当に激しく争われているクリティカルセクションでのみ重要です。

わからない、多分私はそれをやりすぎているのかもしれない...しかし何かがこれについて私を悩ませている。任意の洞察をいただければ幸いです。ありがとう ;）

windows に変換されるものはブーストにありますCRITICAL_SECTIONか?
CRITICAL_SECTIONブロックの代わりにスピンロックを使用し、カーネルへの高価な移行を回避する、いわゆる「ユーザーモード」ミューテックスです。

ミューテックスを使用してグローバルダブルを保護する例に取り組んでいますが、エラーが発生します-

Lab7.exe の 0x77b6308e で未処理の例外: 0xC0000005: アクセス違反の書き込み場所 0x00000068。

これはスコアへのアクセスに関連していると思いますか？(グローバルダブル)

アップデート：

ループが 10 ではなく 1000 に設定されている問題を修正した後もエラーが発生しましたが、ミューテックスを参照するコードをコメントアウトしたところ、エラーは発生しませんでした。

更新 2

慣習に従って、スレッドは 0 を返します (長い 1 週間でした!)

私はミューテックス関連のコードを追加しようとしましたが、CRITICAL_SECTION、InitializeCriticalSection、およびDeleteCriticalSectionがすべて追加された状態で、プログラムはコンパイルされて正常に実行されます(もちろんダブルの競合状態の問題を除く)。問題はEnterCriticalSectionにあるようですまたは LeaveCriticalSection を追加するとエラーが再発するためです。

オペレーティング システムの概念 (Silberschatz、Galvin、Gagne)、第 6 版、第 20 章を読んでいます。Linux カーネル コードはプリエンプティブルではないことを理解しています (2.6 バージョンより前)。ただし、ハードウェア割り込みによって中断される可能性があります。カーネルがクリティカル セクションの途中で割り込みが発生し、カーネルもクリティカル セクションを実行した場合はどうなりますか?

私が本で読んだことから：

Linux が使用する 2 番目の保護方式は、割り込みサービス ルーチンで発生するクリティカル セクションに適用されます。基本的なツールは、プロセッサの割り込み制御ハードウェアです...

このスキームは、ISR にクリティカル セクションがある場合に使用されます。ただし、それ以上の割り込みを無効にするだけです。そもそも、この割り込みによって中断されたカーネル コードはどうなるのでしょうか?

ファイルの読み取りと書き込みを行うクラスを作成する必要があります。書き込み操作を行うと、読み取りは行われず、その逆も同様です。そのために単一のクリティカル セクション オブジェクトを使用できますか? このような：

FileWorker.h

FileWorker.cpp

ありがとう。

WebサービスのCOMdllを使用しています。COMdllが参照として追加されます。そして、Global.asaxでオブジェクトを静的として宣言しています。Application_StartでCOMオブジェクトを作成しています。

リクエストごとにCOMdllインターフェイス関数を呼び出す必要があります。ここでは、メモリの破損として例外が発生しています。同時リクエストが発生したときに発生するログを確認できました。そのための最善の方法を教えてください。スレッドセーフにする方法。

マルチスレッドの Linux アプリケーションでは、クリティカル セクションにミューテックスを使用しています。これは、公平性の問題を除けば非常にうまく機能します。スレッドがクリティカル セクションを離れてすぐに再入力しても、他のスレッドにチャンスが与えられない場合があります。例えば

他のスレッドが同じクリティカル セクションに入るのを止める可能性が非常に高いです。Mutexe は公平ではありません。

公正なクリティカル セクションを作成するための解決策はありますか? クリティカルセクションが「到着」順に実行されるように、キューを追加することを考えていました。または、少なくとも、他のスレッドが待機している場合にロック解除後に pthread_yield() を実行するためのカウンター。

この種の要件に対して推奨される方法はありますか?

インターロックされた変数アクセスとクリティカルセクションのインターロックされたインクリメントの違いをc ++で説明できる人はいますか? よろしくお願いします。

最近、この警告が表示されました (VC++ 2010)

warning LNK4210: .CRT section exists; there may be unhandled static initializers or terminators

これがクリティカルセクションだと思います。オペレーティング システムのコースを受講してからしばらく経ちましたが、これが何を意味するのかよくわかりません。私の記憶が正しければ、クリティカル セクションは共有リソースで機能します。では、この警告はどのように関連しており、正確には何を意味するのでしょうか?