web-dev-qa-db-ja.com

専用スレッドロックオブジェクトの命名規則

比較的軽微な質問ですが、公式のドキュメントや、ブログに関する意見や議論すら見つけられませんでした。

簡単に言うと、プライベートlockを提供することを唯一の目的とするプライベートオブジェクトがある場合、そのオブジェクトにどのような名前を付けますか？

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

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

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

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

  1. SyncRoot（および__syncRoot_などのバリエーション）の豊富な使用法。

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

  2. MSDN記事のthisLockおよびlockThis： C＃lock Statement 、 VB SyncLock Statement

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

  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ロックステートメント」のC＃仕様には、このパターンの例があり、synchronizationObjectという名前が付けられています

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

質問：あなたの意見は一般的に命名についてprivateオブジェクトをロックしますか？

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

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

c#namingmultithreadingvb.net
16
Chris Sinclair

私はそれを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つのオブジェクトが複数のリソースをロックしている場合があります。その場合は、何らかの方法で名前にそれを尊重させようとするため、読者は「これらの個々のリソースの他のロックもこのロックと競合している」ことを知っています。

4
Jimmy Hoffa

私は通常それを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...
            }
        }
    }
}
6
Jesse C. Slicer

私はいつもlck_を使いました。この方法でctrl + f 'lck'を実行すると、ロックのみが検出されますが、 'lock'は 'clock'なども検出します。

LockThisやPadlockのようなものはuniポートフォリオでは問題ありませんが、適切なプロジェクトでは、セマンティック名を実際に使用して、宣言を見ると、コードを検索しなくてもオブジェクトが実際に何を行うかがわかるようにする必要があります。

2
Inverted Llama