専用スレッドロックオブジェクトの命名規則[非公開]

比較的マイナーな質問ですが、公式のドキュメントやブログに関する意見/議論すら見つけることができませんでした。

簡単に言えば、私が唯一の目的をprivateに提供することを目的とするprivateオブジェクトがある場合、そのオブジェクトlockに何と名前を付けますか？

class MyClass
{
    private object LockingObject = new object();

    void DoSomething()
    {
        lock(LockingObject)
        {
            //do something
        }
    }
}

LockingObjectここで何と名付けるべきですか？また、変数の名前だけでなく、ロック時にコード内でどのように見えるかを考慮してください。

さまざまな例を見てきましたが、しっかりしたアドバイスはないようです。

1. の多数の使用法SyncRoot（およびなどのバリエーション_syncRoot）。

   • コードサンプル： lock(SyncRoot)、lock(_syncRoot)
   • これは、VBの同等のSyncLockステートメント、SyncRootICollectionクラスのいくつかに存在するプロパティ、およびある種のSyncRootデザインパターンの一部に影響を受けているようです（おそらく悪い考えです）
   • C＃コンテキストにいるので、VBishの名前を付けたいかどうかはわかりません。さらに悪いことに、VBでは、変数にキーワードと同じ名前を付けます。これが混乱の原因になるかどうかはわかりません。

2. thisLockおよびlockThisMSDNの記事から：C＃lockステートメント、VB SyncLockステートメント

   • コードサンプル： lock(thisLock)、lock(lockThis)
   • これらが例のために最低限純粋に命名されたかどうかはわかりません
   • staticクラス/メソッド内でこれを使用している場合、ちょっと変です。
   • 編集：ロックに関するウィキペディアの記事も、この命名を例に使用しています

3. PadLock（さまざまなケーシングの）のいくつかの使用法

   • コードサンプル： lock(PadLock)、lock(padlock)
   • 悪くないが、私の唯一の牛肉は、それは当然の画像呼び出した物理私は関連付けるていない傾向があり、「南京錠」抽象スレッドのコンセプトを。

4. ロックするものに基づいてロックに名前を付ける

   • コードサンプル： lock(messagesLock)、lock(DictionaryLock)、lock(commandQueueLock)
   • VB SyncRoot MSDNページの例にはsimpleMessageList、プライベートmessagesLockオブジェクトの例があります
   • 実装の詳細は変更される可能性があるため、ロックしている型（「DictionaryLock」）に対してロックに名前を付けることは良い考えではないと思います。ロックしているコンセプト/オブジェクト（ "messagesLock"または "commandQueueLock"）に名前を付けることを好みます
   • 興味深いことに、コードサンプルのオブジェクトをオンラインまたはStackOverflowでロックするためのこの命名規則はほとんどありません。

5. （編集）セクション「8.12 The Lock Statement」のC＃仕様には、このパターンの例があり、名前が付けられています synchronizationObject

   • コードサンプル： lock(SynchronizationObject)、lock(synchronizationObject)

質問：プライベートロックオブジェクトの命名 に関する一般的な意見は何ですか？

最近、私はそれらに名前を付け始めましたThreadLock（オプション3のようなものです）が、その名前に疑問を感じています。

私は頻繁にこのロックパターン（上記のコードサンプル）をアプリケーション全体で使用しているため、それらの堅実な命名規則についてより専門的な意見/議論を得ることが理にかなっていると思いました。ありがとう！

アクセス/更新するためにロックが必要なものを呼び出すという習慣になりSomeResourceLockましたSomeResource（つまり、スレッドの問題を許してください、これは単なる例示です）

public class ProcessDataInQueue
{
    private static Queue<Data> _dataQueue = new Queue<Data>();
    private static object _dataQueueLock = new Object();

    public void AddOneItem(Data itemToAdd)
    {
        lock(_dataQueueLock)
        {
            _dataQueue.Enqueue(itemToAdd);
        }
    }

    public void ProcessOneItem()
    {
        Data itemToProcess = null;
        lock(_dataQueueLock)
        {
            itemToProcess = _dataQueue.Dequeue();
        }
        // ... process itemToProcess
    }
}

さまざまなリソースに対して複数のロックを設定できるクラスを作成した後、この習慣に遭遇しました。そのため、アクセスをロックしているリソースに基づいてロックオブジェクトに名前を付けます。1つのオブジェクトが複数のリソースをロックしている場合があります。その場合、何らかの方法で名前を尊重させようとするため、読者は「これらの個々のリソースの他のロックもこのロックと競合する」ことを知っています。

私は通常それを呼び出しますlockerが、それはプライベートなので、やや重要でない実装の詳細だと思います。経験則として、チーム/会社の標準を使用します。存在しない場合は、それを作成して使用してください。ただし、作成するときは、物事をシンプルにしてください。クラスに単一のロックオブジェクトがある場合、それを呼び出すfooだけで十分です。多数ある場合、ビジネスの良い順序は、そのクラスの設計を最初に再検討して、あまりにも多くの異なることを行っているかどうかを確認することです。しかし、そうでない場合、この完全に不自然な例のように、名前が重要になります。

public sealed class CustomerOrders
{
    private readonly object customerLocker = new object();

    private readonly object orderLocker = new object();

    public IEnumerable<Customer> Customers
    {
        get
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            lock (this.orderLocker)
            {
                // other stuff...
            }
        }
    }

    public IEnumerable<Order> Orders
    {
        get
        {
            lock (this.orderLocker)
            {
                // stuff...
            }
        }

        set
        {
            lock (this.cutomerLocker)
            {
                // different stuff...
            }
        }
    }
}

常にlck_を使用しました。ctrl + f 'lck'を使用すると、ロックのみが検出され、 'lock'は 'clock'なども検出されます。

lockThisやPadlockのようなものはuniポートフォリオには適していますが、適切なプロジェクトでは、セマンティック名を実際に使用する必要があります。そのため、宣言を見るときに、コードを検索せずにオブジェクトが実際に何をするかを知ることができます。