問題タブ [locking]

public int counterクラスに複数のスレッドがアクセスするフィールドがあるとしましょう。これintはインクリメントまたはデクリメントされるだけです。

このフィールドをインクリメントするには、どのアプローチを使用する必要がありますか、またその理由は何ですか？

• lock(this.locker) this.counter++;、
• Interlocked.Increment(ref this.counter);、
• のアクセス修飾子をに変更しcounterますpublic volatile。

私が発見したvolatileので、私は多くのlockステートメントとの使用を削除してきましたInterlocked。しかし、これを行わない理由はありますか？

マルチスレッドの理解を固めようとしています。私は自分自身を教えるために最善を尽くしていますが、これらの問題のいくつかは明確にする必要があります.

コードの一部を 3 回繰り返し、ロックを試してみました。

このコードで、ロックが必要なのは this.managerThreadPriority だけです。

まず、最小限のロックを使用した単純な手続き型アプローチです。

次に、新しいスレッドを作成して起動する単一のステートメントですが、ロックの範囲が大きすぎて、スレッドの作成と起動を含めることができません。コンパイラは、 this.managerThreadPriority が使用された後にロックを解放できることを魔法のように知りません。

この種の素朴なロックは避けるべきだと思います。

最後に、共有フィールドの周りにのみ「埋め込み」ロックを使用して、新しいスレッドを作成して起動する単一のステートメントです。

lock ステートメントのスコープについてコメントしますか? たとえば、ifステートメントでフィールドを使用する必要があり、そのフィールドをロックする必要がある場合、ステートメント全体をロックしないようにする必要がありますifか? 例えば

対。

私は、キャッシュに値するほぼすべてのものを対象とした動的なエージング キャッシュとして機能するように設計された CFC を構築しました。LDAP クエリ、関数の結果、配列、オブジェクト、名前を付けます。計算に時間やリソースがかかり、複数回必要とされるもの。私はいくつかのことをできるようにしたいと思います:

• アプリケーション間で CFC を共有する
• キャッシュのスコープを定義する (サーバー / アプリケーション / セッション / 現在のリクエストのみ)
• 同じリクエストで同時に異なるキャッシュ インスタンスを使用する
• キャッシュ コンポーネントを使用して CFC から独立させる
• 一般的に常識に従う（デカップリング、カプセル化、直交性、ロック）

もちろん、個別のタスクごとに異なるキャッシュ インスタンスを使用しますが、アプリケーション間で同じ CFC を使用できるようにしたいと考えています。キャッシュ自体は (それ以外は) Struct であり、キャッシュ インスタンスに対してプライベートです。スコープ自体が変更される可能性がある場合、キャッシュとロックを適切に実装するにはどうすればよいですか?

ロックには、現在、名前付きロック ( 'CacheRead'、'CacheWrite') を使用しています。これは安全ですが、奇妙に感じます。たとえば、セッションのみの操作でサーバー全体のロックが必要になるのはなぜですか? (はい、これはアカデミックかもしれませんが、ともかく。)

アプリケーションレベルのキャッシュが必要な場合に参照として APPLICATION スコープを渡すことも間違っているようです。より良い方法はありますか？

私は「ダブルチェックロック」に関するこの記事を読んでいて、記事のメイントピックから離れて、なぜ記事のある時点で著者が次のイディオムを使用するのか疑問に思っていました:

リスト 7. 順不同の書き込み問題の解決を試みる

そして私の質問は、同じロックでコードを 2 回同期する理由はありますか? これは何か目的がありますか？

よろしくお願いします。

私は持っていDictionary<string, someobject>ます。

編集：私の例が悪いと指摘されました。私の全体的な意図は、ループ内の参照を更新することではなく、データを更新/取得する必要があるさまざまなスレッドに基づいてさまざまな値を更新することでした。ループをメソッドに変更しました。

ディクショナリ内の項目を更新する必要があります - 一度に 1 つのキーで、ディクショナリ オブジェクトの .key 値のロックを使用する際に問題があるかどうか疑問に思っていましたか?

それは法廷で持ちこたえるか、それとも失敗しますか? ディクショナリ内の各値を個別にロックして、1 つの値をロック (および更新) しても他の値がロックされないようにしたいだけです。また、ロックが長時間保持されることは承知していますが、完全に更新されるまでデータは無効になります。

どちらも同じ目的を果たしているようです。いつ私はどちらか一方を選びましたか？

ロックについて質問です。これは、レコードのロックだけに限ったことではありません。

私が Web アクセス可能な CMS を書いているとしましょう。私はいくつかのアイデアに苦労しています。

ユーザーが編集のために記事を開いた瞬間に、記事に「使用中」のフラグを立てることができます。ここまでは順調ですね。

しかし、いつフラグを削除するのですか? ユーザーが記事を保存したとき しかし、ユーザーがもうタイピングする気になれず、ブラウザを閉じて就寝することにした場合はどうなるでしょうか。

タイムアウトの仕組みが頭に浮かびますが、記事を書くのにどれくらいの時間がかかりますか? 10分短すぎて30分長すぎ…

多分私はこれを過度に複雑にしています。この件についてあなたの考えを聞きたいです。

への関数呼び出しの形式で要求を処理するマルチスレッド C++ プログラムがあるとしhandleRequest(string key)ます。への各呼び出しhandleRequestは個別のスレッドで発生し、 には任意の数の可能な値がありkeyます。

次の動作が必要です。

• の同時呼び出しhandleRequest(key)は、 の値が同じ場合にシリアル化されkeyます。
• グローバルなシリアライゼーションは最小限に抑えられます。

の本体は次のhandleRequestようになります。

質問:必要な動作を得るためにどのように実装KeyLockしますか?

単純な実装は、次のように開始できます。

...しかし、それには各リクエストの最初と最後にグローバル ロックが必要であり、リクエストLockごとに個別のオブジェクトを作成する必要があります。への呼び出し間の競合が高い場合はhandleRequest問題にならない可能性がありますが、競合が少ない場合は多くのオーバーヘッドが発生する可能性があります。

このようないくつかのaspチュートリアルでは、次のパターンを観察します。

アプリケーション.ロック

'アプリケーションオブジェクトでいくつかのことを行います

アプリケーション.ロック解除

ただし、Web ページには複数のインスタンスを含めることができるため、明らかに並行性の問題があります。だから私の質問は次のとおりです。

オブジェクトがすでにロックされているときに、あるページをロックしようとするとどうなりますか?

アプリケーション オブジェクトがロックされているかどうかを検出する方法はありますか?

ロックされていないアプリケーション オブジェクトで作業する方が良いですか、それとも他の結果がありますか?

アプリケーション オブジェクトに関連するアクションが 1 つしかない場合はどうなるでしょうか。〜その場合、ロック/ロック解除する理由はありますか?

マルチスレッドコードでは、インスタンスが複数のスレッドによって読み取りまたは書き込みされる可能性がある場合、これらの操作を安全に実行するには、インスタンスをロックオンする必要があります。

ロックするオブジェクトの作成とコードによる一連のロックステートメントの記述の繰り返しを避けるために、ロックを処理するジェネリッククラスを作成しました。

概念的に、私は何かが欠けていますか？これはうまくいくはずですよね？

そして、クラスで使用されている例：

また、このようなものを自動化された方法でテストするにはどうすればよいですか（単体テストの作成など）？

最後に、これを回避するために、++および--演算子を実装するために何ができますか？