2

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

    Private Lock1 As New Object ' declaration
    SyncLock Lock1 ' usage

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

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

    Private cmdQueue As New Queue(Of QueueItem) ' declaration
    SyncLock cmdQueue ' usage

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

編集：

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

4

4 に答える 4

3

確かに他のポスターからの賢者のアドバイス。しかし、答えは「はい」です。Queueオブジェクトを使用してロックすることができます。任意のオブジェクトを使用できます。また、コードスニペットでキューインスタンスをプライベートとして宣言したため、他の誰かがキューオブジェクトをロックするという一般的な問題を回避できる可能性があります（オブジェクトをクラスの外部に渡さないと仮定します）。ただし、ベストプラクティスでは、専用のオブジェクトを使用して、将来的に誰かがコードを変更せず、ロックに使用されているキューオブジェクトを公開しないようにすることをお勧めします。

于 2012-06-08T15:48:38.703 に答える
2

これは、ロックに関する一般的な誤解です。ロックの役割はコードをブロックすることであり、オブジェクトにスレッドセーフを与えることではありません。オブジェクトは、ロックの状態を追跡するためだけにあります。また、特定のコードをブロックする必要があるため、ロック状態を格納するための特定のオブジェクトが必要になります。パブリックキューは十分に具体的ではなく、他の場所で他のコードによって使用されることになります。また、キューオブジェクトを悪用して独自のコードをブロックしている場合は、厄介なデッドロックの問題が発生する可能性が高くなります。

スレッドセーフを実装するためにオブジェクトをロックするという概念は実際に存在します。これは、私のマシンには決して届かないように思われる、熱心な研究の対象です。これはSTM、「ソフトウェアトランザクショナルメモリ」と呼ばれます。ウィキペディアの記事はこちらです。

于 2012-06-08T12:13:20.847 に答える
1

問題は、他の人があなたのオブジェクトをロックする可能性があり、それがあなたのコントロールの外にあることです。このロックステートメントに関するMicrosoftのベストプラクティスを参照してください

于 2012-06-08T10:41:38.463 に答える
-1

ロックされたオブジェクトは変更されないままでなければならないので、あなたがすることは悪い習慣だと思います。をロックしてQueue(Of QueueItem)から同じキューからデキューすると、オブジェクトが変更され、ここに記載されているように：https ://msdn.microsoft.com/en-us/library/3a86s51t.aspx （2番目のルール）、

このメカニズムでは、ロックオブジェクトを変更しないでおく必要があります。

だからあなたはこのようPublic StatusObject As New Objectにしてそれをロックする必要があります

于 2016-08-01T20:51:38.557 に答える