問題タブ [synclock]

スレッド管理のウェイターを使用しました。

SyncLock http://msdn.microsoft.com/en-us/library/3a86s51t%28v=vs.71%29.aspx

しかし今、タイムアウトが欲しかったので、WaitOne を見つけました。

単純なタイムアウトをサポートするWaitOne http://msdn.microsoft.com/en-us/library/system.threading.waithandle.waitone.aspx 。

しかし、それはもう機能しません。障害がコードの別の場所にある可能性があります。あなたへの私の主な質問は、基本的なウェイター フラグとして使用することSyncLockと使用することに違いはありますか?WaitOne

よろしく

.Post（）を介してAsyncOperationによって呼び出されるUpdate（）メソッドがあります。その関数にMessageBoxを配置すると、複数のメッセージボックスが表示され、その理由を理解しようとしています。

メッセージボックスは、「OK」がクリックされるまでUpdate（）の実行を停止する必要がありますが、.Post（）が原因で、Update（）が再入力され、前のメッセージボックスが閉じられる前に次のメッセージボックスが表示されます。

私が最初に考えたのは、SyncLockをUpdate（）に配置して、同時に実行できないようにすることでしたが、効果はありませんでした。メッセージボックスに.ManagedThreadIDを出力すると、すべての呼び出しが同じスレッドIDを持つため、SyncLockは異なるスレッドのみをブロックするため、効果がないように見えます。

それで、誰かがここで何が起こっているのか説明できますか？1つのスレッドで同じ機能を同時に実行するにはどうすればよいですか？

私はアンドロイド開発用にアンドロイド仮想デバイスを使用しています.Twitterでステータスを更新するアプリを開発しています.logcatを見ると、システムクロックが同期されていないことが問題だと思います.

ログキャット

完全なコードはここにあります

この記事で説明されているように、値型でロック（SyncLock）を使用できないことはわかっています。

http://msdn.microsoft.com/msdnmag/issues/03/01/NET/

しかし、私の質問は、これは私がする必要がないことを意味するのでしょうか？または、ブール値をオブジェクト内でラップして、ロックできるようにする必要がありますか？答えが「いいえ」の場合、ロックする必要はありません。2つのスレッドが同時に値を変更しようとするとどうなりますか？私が現在取り組んでいるアプリケーションでは、2つのスレッドが同時にtrueとfalseの両方に設定しようとする可能性があります。

私の ASP.NET アプリケーションは、さまざまなデータ チャンクへのアクセスを提供します。各チャンクには 1 人以上のユーザーが同時にアクセスできるため、アプリは競合を防止する必要があります。

多くの検討の結果、オプティミスティック コンカレンシーはこのシナリオに最適なソリューションではないと考えており、現在、適切なオプションとしてロックを検討しています。

SyncLock次のように a を使用して、すべてのリクエストを 1 つずつ簡単に処理できます。

新しいオブジェクトとしてのプライベート共有 AccessLock

しかし、それはアプリケーションのスケーラビリティを大きく制限します。

そのため、データの特定の部分のみへのアクセスを何らかの方法でエンキューすることを考えています。たとえば、あるキューはデータの一部にアクセスするためのもので、別のキューはデータの別の部分にアクセスするためのものです。

すべてに対して 1 つのキューだけでなく、データの異なる部分に対して異なるキューを使用するように同期ロックをカスタマイズする方法はありますか? つまり、「SyncLock (「Group1」) や「SyncLock (「Group2」)」などを手動で指定できるようになるということです。

私は一般的にマルチスレッドにかなり慣れていないので、他のスレッドによって読み取り/更新されている間、共有整数変数を他のスレッドからアクセスされないようにロックする方法を知りたいです。

do do を実行しようとすると、次のエラーSyncLock myIntegerが表示されます。エラー 6 'SyncLock' オペランドは、'Integer' が参照型ではないため、型 'Integer' にすることはできません。

ここに私が意味することの簡単な例があります

MySub は、クラスの複数のインスタンスによって呼び出され、複数のスレッドで実行されます

私はいつもSyncLockの例で人々が使用しているのを見ました

しかし、なぜ？私の特定のケースでは、データのエンキューとデキューのマルチスレッドの問題を回避するためにキューをロックしています。

このように、Queueオブジェクト自体をロックできますか？

助けていただければ幸いです。ありがとう。

編集：

すべての答えに感謝しますが、tcarvinの答えは私が探していたものでした。キューは、送信される新しいメッセージをキューに入れるシングルトンCommsオブジェクトからプライベートであり（Sendメソッドによって公開されます）、キューはこのオブジェクト内のワーカースレッドで一度に1メッセージずつ消費され、ロック内にあるコードは次のとおりです。エンキューとデキューへの1回の呼び出し。

簡単なリストに入れられるさまざまなソースからのメッセージをフィードできるアプリケーション内サービスがあります。独自のスレッドで実行されるサービスは、定期的に、リスト内のすべてのメッセージをさまざまなファイルに処理します。ソースごとに 1 つのファイルが作成され、サイズが管理されます。

私の質問は、メッセージをチェックし、リストにアクセスするコードをロックする適切な方法についてです。リストにアクセスできる場所は 2 つだけです。1 つはメッセージがリストに追加される場所で、もう 1 つはメッセージがリストから処理リストにダンプされる場所です。

リストへのメッセージの追加:

リストの処理:

私の質問は次のとおりです。リストを処理しているときに二重チェックを行う必要がありますか?以下を参照してください。なぜ？または、なぜですか？また、ロックの外でリストの count プロパティにアクセスすることに危険はありますか? どちらの方法がより優れているか、またはより効率的ですか? なぜ？または、なぜですか？

この特定のケースでは、処理関数の外ではリストが大きくなるだけであるという事実を考慮して、二重チェックを行っても問題ない場合があることを理解しています。しかし、これは私の実際の例であり、スレッド化の詳細について学ぼうとしています。

洞察をお寄せいただきありがとうございます…</p>

いくつかのさらなる調査の後、「クーン」に感謝し、いくつかの実験的なプログラミングを行った後、さらにいくつかの考えがあります。

ReaderWriterLockSlimに関しては、うまくいくように見える次の例があります。リスト内のメッセージ数やメッセージ自体を読み取ろうとしている可能性のある他のコードに干渉することなく、リスト内のメッセージ数を読み取ることができます。また、リストを処理したい場合は、ロックを書き込みモードにアップグレードし、メッセージを処理リストにダンプして、読み取り/書き込みロックの外側で処理できるため、追加または読み取りが必要な他のスレッドをブロックしません。 、その他のメッセージ。

この例では、他のメタデータとともに Type を使用した前の例とは対照的に、メッセージに単純な構造体である String を使用していることに注意してください。

この手法に関する唯一の問題は、開発者がロックの取得と解放に熱心に取り組む必要があることです。そうしないと、デッドロックが発生します。

これがSyncLockを使用するよりも効率的かどうかについては、私は本当に言えませんでした。この特定の例とその使用法については、どちらでも十分だと思います。他の誰かがカウントを変更している間にカウントを読み取ることについて「クーン」が与えたまさにその理由について、私は二重チェックを行いません。この例では、SyncLockは同じ機能を提供します。ただし、複数のソースがリストに対して読み取りと書き込みを行う可能性がある、もう少し複雑なシステムでは、ReaderWriterLockSlimが理想的です。

BlockingCollectionリストに関して、次の例は上記のように機能します。

シンプルさそのもの…</p>

別のスレッド (メイン スレッド) から更新される可能性がある間に、(バックグラウンド) スレッドのリストから読み取る必要があります。そのため、元のオブジェクトにアクセスしないように一時的なリストを作成しようとしています。複数の場所で更新が発生する可能性があるため、SyncLock を読み取りロジックに配置すると便利です。それは本質的に間違っていますか？これを正しくロックするためのオプション、またはマルチスレッド状態でリストのアクセス可能なコピーを取得する他の方法は何ですか?

SomeList.ToListスロー:

ArgumentException、Destination 配列の長さが十分ではありません。destIndex と長さ、および配列の下限を確認してください。

オブジェクトの自動更新を管理するクラスに次のコードがあり、手動で更新することもできます。スレッドセーフにしたい。

私はSynclockこれらの方法の両方に誘惑されます：

• ForceRefresh：したがって、複数のコンシューマスレッドが同時に更新を強制し、タイマーをリセットしようとすることはありません。
• DoRefreshGetTheFoo()：ですから、すでに取得しようとしている最中の場合は、そうしようとはしません。System.Threading.Timerいずれかのスレッドでコールバックする可能性のあるものを使用ThreadPoolしているため、フラグを使用するだけでは適切でない場合があります（ただし、それでも必要ですか？）

... このような：

しかし、それから私は電話をするときに2回Synclockオンにしようとすることになります...今、再入可能であれば、これらをネストすることは問題にはなりません。MSDNのドキュメントページは、これが事実であることを示唆しているようですが、明示的には述べていません。_syncRootForceRefreshSynclock

注：これを自分で試してみるつもりですが、StackOverflowでこれについて何も表示されなかったため、回答しておくと便利な質問だと思いました。