私の質問はこのスレッドに似ていますが、特定のスレッドで引き出された結論がここに当てはまるかどうかは確信しています。
私の使用例: アプリケーションには、1 秒ごとに同じテキスト情報を送信するステータス スレッドがあります。文字情報には、アプリケーション グループ名が含まれます。このステータスは、アプリケーション サーバーがオンかオフかを判断するためにステータス リーダーによって使用されます。
アプリケーション グループ名は、存続期間中に変更できるようになりました。ユーザー アクティビティが原因で、アプリケーション内の 1 つのスレッドだけがこのイベントをトリガーすることが保証されます。これで、この単一のスレッドに、ステータス スレッドに更新する必要がある新しいアプリケーション グループ名が付けられました。
私の現在の実装は次のとおりです
ステータス スレッド Main() ReadLock の取得 アプリケーション グループ名の読み取り ReadLock の解放
ステータスを送る
Updater Thread Main() Taken write Lock グループ名の更新 WriteLock の解除
ただし、大量の更新が送信されるため、負荷が高いとパフォーマンスが低下するのではないかと心配しています。そのため、次の実装に取り組んでいますが、これが機能するかどうかはわかりません。
新しく提案された実装は
- 送信側スレッドは、char* ptr、char[1024] primaryData、char[1024] secondaryData を保持します。
- 初めてアプリケーションを起動すると、グループ名は primaryData で更新され、ptr は primaryData を指します。
- 更新スレッドが更新イベントを持っているときはいつでも、(ptr == primaryData) 新しいアプリケーション名を secondaryData にコピーします。 ptr = secondaryData そうでない場合は、新しいアプリケーション名を primaryData にコピーします。ptr = プライマリ データ
- ステータス スレッドは、常に ptr が指すデータを使用してステータスを送信します。ステータス スレッドは最終的に更新された ptr を受け取り (キャッシュの一貫性を考慮して)、新しいデータの送信を開始します。
ここで考慮すべき点がいくつかあります。1. 新しいデータがステータス スレッドですぐに利用できなくても問題ありません。 2. 無効なメモリ アクセスによるプログラムのクラッシュは避けたいです。
友達、上記のロジックが読み書きロックを回避するのに役立つかどうか教えてください。