問題タブ [locking]

.NET 2.0 の ReaderWriterLock と .NET 3.5 の ReaderWriterLockSlim を見てきましたが、スリム バージョンではロックにカーネル オブジェクトを使用していません。大量の (しかし巨大ではない) 量のオブジェクトを生成する可能性がある私のコンテキストでは、これは良いように思えます。

しかし、私が書いたコードは、移行期間中に .NET 2.0 と 3.5 の両方で使用する必要があるため、3.5 バージョンは私の目的には適しているように見えますが、使用できません。

.NET 2.0 にプラグインして同じ利点を得ることができる同様のクラスを持っている、または知っている人はいますか?

複数のステーションから大量のデータを同時に挿入すると同時に、データクエリインターフェイスを公開するシステムがあります。スキーマは次のようになります（フォーマットが不適切なため申し訳ありません）。

データの挿入は「同期」で行われ、次のようになります（システムにデータを挿入するだけで、更新することはありません）

そして、クエリは次のようになります（特定のステーション、測定時間、およびデータ型に対して）

私の質問は、挿入のトランザクションレベルとクエリのNOLOCK/READPASTヒントをどのように組み合わせて次のようにすることができるかです。

1. 挿入を優先しながら、システムの同時実行性を最大化します（大量のデータを保存する必要があり、1秒あたり2000以上のレコードが必要です）
2. クエリは、「コミットされた」同期からのデータのみを返します（半分挿入された同期、またはロックスキップのためにスキップされたエントリとの同期を含む結果セットは必要ありません）
3. 「最新の」データがクエリに含まれているかどうかは関係ありません。「ライブ」で最新のデータよりも一貫性と応答性を重視します。

これは非常に相反する目標であり、高いトランザクション分離レベルが必要になる場合がありますが、挿入と選択の両方で高い応答性を実現するためのすべてのトリックと最適化に関心があります。より多くの微調整やトリックを洗い流すためにさらに詳細が必要な場合は、喜んで詳しく説明します。

更新：将来の返信のためにもう少し情報を追加するだけです。最初は5TB以上のストレージを備えたSANネットワークでSQLServer2005（おそらく6か月以内に2008年）を実行しています。SAnが設定されているRAIDの種類と、使用可能なディスクの正確な数がわかりません。

特にトランザクションに関して、サイトの SQLite パフォーマンスを改善することを検討しています。本質的に、私が探しているのは、データベースへの書き込みをプロセス内で延期して、すべてを一度に実行できるようにする方法です。ただし、更新クエリを蓄積している間、他のプロセスがデータベースからの読み取りと書き込みの両方を実行できるようにし、プロセスでコミットが発行されたときにのみ書き込み用にファイルをロックしたいと考えています。

ドキュメントを見ると、トランザクションで更新コマンドが発行されると、プロセスは RESERVED ロックを取得するように見えます。これは、(私の記憶が正しければ) 更新クエリを独自のトランザクションに追加しようとする他のプロセスを意味します。またはトランザクションをコミットすることはできないため、トランザクションがロックされたプロセスでコミットされるまでブロックされます。

この特定の機能には、データの整合性に関する非常に優れた理由があると確信しています。私が言えることは、私の場合、これらの更新を同時に実行しても危険はないということだけです。

1 つの解決策は、各プロセスで呼び出したいクエリのテキストを配列に蓄積し、書き込みの準備ができたらループダウンすることですが、SQLite トランザクションを実行できるかどうか疑問に思っています。これを自動的に行ってください。

更新:「すべての更新を一度に行う」というのは、基本的に SQLite でトランザクションを使用して、クエリごとではなく、プロセスごとに 1 回だけ排他ロックを取得してディスクに書き込むことです。これにより、SQLite を使用すると 100 倍のスピードアップが実現します。

いくつかの基本的なテストを行ったところ、トランザクションにクエリを追加する複数のプロセスがあると、そのプロセスが RESERVED ロックを取得しようとする更新クエリにヒットしたようです。予約されたロックを持つことができるプロセスは 1 回だけであるため、ロックを取得しようとする他のプロセスは、ロックを持つプロセスがトランザクションを終了するまでブロックされます。

私はまだパフォーマンスの低下に遭遇していないので、この問題は時期尚早の最適化である可能性があることを認めますが、いくつかの簡単なテストを実行し、100 人のユーザーがそれぞれ 100 個のクエリを使用してトランザクションを作成および実行するのに、私のマシンの PHP で約 4 秒かかりました。

どのような場合に <cflock scope="application"> を使用するのが適切ですか? または <cflock name="foo"> とは対照的に、それは同類ですか?

具体的には、CFLock を使用してアプリケーション、セッション、またはサーバー スコープ内の共有オブジェクトを保護することに関心がありますが、ColdFusion でのロックのさまざまな用途についても知りたいと思っています。

〜50K行のデータベーステーブルがあり、各行は実行する必要があるジョブを表しています。DBからジョブを抽出し、ジョブを実行して結果をdbに戻すプログラムがあります。（このシステムは現在稼働中です）

ここで、複数の処理タスクがジョブを実行できるようにしたいのですが、タスクが 2 回実行されないようにします (これが他の問題を引き起こすのではないというパフォーマンス上の懸念から)。アクセスはストアド プロシージャを介して行われるため、私の現在の方法は、ストアド プロシージャを次のようなものに置き換えることです。

ところで; ワーカーのタスクは、ジョブの取得と結果の送信の間の接続を切断する可能性があります。また、その部分を台無しにしない限り、DBがボトルネックに近づくことさえないと思います（1分あたり〜5ジョブ）

これに問題はありますか？これを行うより良い方法はありますか？

注: 「IPC アンチパターンとしてのデータベース」は、ここでは少しだけ適切です。

1. 私はIPCを行っていません（行を生成するプロセスはありません。現在、それらはすべてすでに存在しています）
2. そのアンチパターンについて説明されている主な不満は、プロセスがメッセージを待機するときにDBに不要な負荷がかかることです（私の場合、メッセージがない場合、すべてが完了するとすべてがシャットダウンする可能性があります）

Win+Lホットキーを別の実行可能ファイル/ショートカットに再割り当てすることはできますか?

ユースケース - ラップトップのモニターがロックされたらすぐにオフにしたいと考えています。モニターをロックして電源を切ることができる実行可能ファイルは知っていますが、システムがロックされる方法を変更したくありません (プログラムを明示的に実行するか、他のショートカットを使用して)。Winこの実行可能ファイルに+Lを割り当てることができれば最高です。

誰かが次の違いを説明できますか:

• ロック (someobject) {}
• ミューテックスの使用
• セマフォの使用
• モニターの使用
• その他の .Net 同期クラスの使用

私はそれを理解することはできません。最初の2つは同じように思えますか？

スレッドプールのタスクを生成するマネージャー クラスがあり、各スレッドは終了後にコールバックを行うことになっています。

ロックを使用して変数とフィールドを処理し、シグナルを使用してスレッド間通信を処理します。私が探しているのは、現在の lock() を終了し、SignalAndWait のような信号をアトミックに待つ方法ですが、locks() の場合です。

コードは次のようになります。

ここでの問題は、.WaitOne() が lock() を終了しないため、コールバックを実行するスレッドがデッドロックすることです。

私は WaitOne(Int32, bool exitContext) に大きな期待を寄せていましたが、そのコンテキストは同期ではなくリモート処理などに関するものであるようです。

アプリケーション スコープで作成されたコードをロックする必要があるかどうか疑問に思っています。アプリケーション スコープで userDAO.cfc というオブジェクトを作成すると、すべてのページで使用できるようになります。次に、そのオブジェクトに、アプリケーションのさまざまな部分で呼び出される getUserInfo(userID) というメソッドがある場合、このメソッドをロックする必要がありますか?

「インスタンスフィールドの遅延初期化のためのダブルチェックイディオム」を検討してください。

/blockquote>

フィールドを安全な方法でリセットできるようにしたい (私の場合は、データベースから強制的に再度ロードする)。reset メソッドを使用することでこれを行うことができると思います。

/blockquote>

これは、フィールドをリセットする標準的な方法ですか? 安全ですか？落とし穴はありますか？ブロッホがダブルチェック遅延読み込みについて次の警告を出したので、私が尋ねているのです。良い考えではありませんが、ここでは適切です。」

ヒマラヤのプラヤさん、よろしくお願いします。