問題タブ [readwritelock]

私はワークフローのようなシステムに取り組んでいます。1 つのタスク テーブルとステータス フィールドがあります。status の値は、New、ready、processing、error、abort、done のいずれかです。

タスクステータスの値を変更するために、さまざまな状況に基づいてトリガーされる約7つのプロセスがあります。ほとんどの場合、各プロセスは独自のデータ セットで動作し、毎回最大 5000 レコードしか処理しません。しかし、データが約 200 万レコードに達すると、まだデッドロックが発生します。SQL プロファイラで確認すると、関連するページ リソースのように見えます。私はSQLサーバーのパフォーマンスチューニングが苦手で、よく理解していません。

非アクティブなタスクは毎日アーカイブされるため、1,000 万件程度のレコードをサポートするようにテーブルを再設計することを考えています。

いくつかの選択肢があります:

1. ステータスに基づいて分割テーブルを作成します。
2. ステータスに基づいて静的データとサポートされているテーブルを含むマスター テーブルを作成する

この種の状況に適した方法はありますか?

ありがとう！

私の質問はこのスレッドに似ていますが、特定のスレッドで引き出された結論がここに当てはまるかどうかは確信しています。

私の使用例: アプリケーションには、1 秒ごとに同じテキスト情報を送信するステータス スレッドがあります。文字情報には、アプリケーション グループ名が含まれます。このステータスは、アプリケーション サーバーがオンかオフかを判断するためにステータス リーダーによって使用されます。

アプリケーション グループ名は、存続期間中に変更できるようになりました。ユーザー アクティビティが原因で、アプリケーション内の 1 つのスレッドだけがこのイベントをトリガーすることが保証されます。これで、この単一のスレッドに、ステータス スレッドに更新する必要がある新しいアプリケーション グループ名が付けられました。

私の現在の実装は次のとおりです

1. ステータス スレッド Main() ReadLock の取得 アプリケーション グループ名の読み取り ReadLock の解放

   ステータスを送る

2. Updater Thread Main() Taken write Lock グループ名の更新 WriteLock の解除

ただし、大量の更新が送信されるため、負荷が高いとパフォーマンスが低下するのではないかと心配しています。そのため、次の実装に取り​​組んでいますが、これが機能するかどうかはわかりません。

新しく提案された実装は

1. 送信側スレッドは、char* ptr、char[1024] primaryData、char[1024] secondaryData を保持します。
2. 初めてアプリケーションを起動すると、グループ名は primaryData で更新され、ptr は primaryData を指します。
3. 更新スレッドが更新イベントを持っているときはいつでも、(ptr == primaryData) 新しいアプリケーション名を secondaryData にコピーします。 ptr = secondaryData そうでない場合は、新しいアプリケーション名を primaryData にコピーします。ptr = プライマリ データ
4. ステータス スレッドは、常に ptr が指すデータを使用してステータスを送信します。ステータス スレッドは最終的に更新された ptr を受け取り (キャッシュの一貫性を考慮して)、新しいデータの送信を開始します。

ここで考慮すべき点がいくつかあります。1. 新しいデータがステータス スレッドですぐに利用できなくても問題ありません。 2. 無効なメモリ アクセスによるプログラムのクラッシュは避けたいです。

友達、上記のロジックが読み書きロックを回避するのに役立つかどうか教えてください。

スレッド セーフのために ReaderWriterLockSlim を利用する多くのプロパティを実装しようとしています。したがって、ほとんどの場合と同様に、すべてのプロパティで次のような結果になります。

これは 10 個のプロパティで非常に冗長で反復的な感じがするので、より DRY な実装を探しています。

明らかな解決策は、破棄時にロックを解放し、スレッド セーフな操作を using ステートメント内に配置できるようにするクラスにラップすることです。これと他のいくつかの情報源によると、明らかにこれはあまり安全ではありません。

そこで、ラムダ式と匿名メソッドを使用して見栄えの良いソリューションを考え出そうとしました。

これにより、私を悩ませていた繰り返しコードがなくなりましたが、元の詳細な実装と同じくらいスレッドセーフかどうかはわかりません。

これが生成する MSIL とマルチスレッド理論をよりよく理解している人は、私の実装が安全かどうかを教えてくれますか?

重複の可能性：
マルチスレッド環境でSTLコンテナーへの読み取りアクセスを保護する必要がありますか？

別のスレッドがこのセットまたはマップに書き込んでいるときに、あるスレッドが：setまたは：mapを読み取った場合、どうなりますか？例外？

現在、読み取り/書き込みロックを使用していますが、書き込み操作は頻繁ではなく、読み取り操作は非常に頻繁であるため、ロックを削除したいと思います。

以下は、典型的なリーダーとライターのパターンです (読み取りが多く、書き込みが少ない)。

ライターとリーダーを優先することは可能ですか？たとえば、通常、ライターは、他のスレッドによって保持されている読み取りロックが常に保持されている場合、非常に長い時間 (おそらく永遠に) 待機する可能性があるため、より高い優先度のライターを使用することは可能ですか?優先度の高い（スキップライン）そのようなもの。

リーダー/ライター ロックで保護する必要がある一連のデータ構造があります。私はboost::shared_lockを認識していますが、std::mutex、std::condition_variable、および/またはstd::atomicを使用してカスタム実装を行い、それがどのように機能するかをよりよく理解できるようにしたいと考えています(後で微調整します) .

各データ構造 (移動可能だがコピー可能ではない) は、ロックをカプセル化する Commons と呼ばれるクラスから継承されます。パブリック インターフェイスを次のようにしたいと思います。

...一部の人が公に継承できるように：

私は科学的なコードを書いており、通常はデータ競合を回避できます。このロックは主に、おそらく後で行う間違いに対する保護手段です。したがって、私の優先順位は低い読み取りオーバーヘッドであるため、正しく実行されているプログラムをあまり妨げません。各スレッドは、おそらく独自の CPU コアで実行されます。

リーダー/ライター ロックを表示していただけますか (疑似コードは問題ありません)。私が今持っているのは、ライターの飢餓を防ぐバリアントであるはずです。これまでの私の主な問題は、読み取りが安全かどうかを確認して実際にリーダーカウントをインクリメントするまでの read_lock のギャップでした。その後、write_lock は待機することを認識しています。

私はマルチスレッドに慣れていないので、本当に理解したいと思っています。よろしくお願いします。

QReadWriteLock を再帰モードで使用しています。

このコードはそれ自体では意味がありませんが、ここから発生した問題は次のとおりです。

lockForRead がブロックされています。これは再帰モードであることに注意してください。

私が見る方法は、書き込みが「優れた」ロックであるということです。これにより、保護されたデータの読み取りと書き込みが可能になります。読み取りロックでは読み取りのみが許可されます。

また、唯一のリーダーが書き込みロックを要求しているのと同じ場合、書き込みロックはブロックされるべきではないと思います。

qreadwritelock.cpp ソースコードから、私が望むように動作させる試みがないことがわかります。したがって、これはバグではなく、欠けている機能です。

私の質問はこれです、この種の再帰は許可されるべきですか? この種の実装から生じる問題はありますか? また、それは何でしょうか?

私は、読者が二重チェックのロックを使用して書き込みロックを取得する Java ReadWriteLock を作成しました。これは安全ではありませんか (遅延インスタンス化を使用した DCL の場合と同様)?

Java には既に ReentrantReadWriteLock があることを知っています。DCL のどの形式が安全かどうかを判断する方法についての一般的な質問に興味がありますか?