전용 스레드 잠금 개체의 명명 규칙 [닫힘]

비교적 사소한 질문이지만 공식 문서 나 블로그 의견 / 토론을 찾을 수 없었습니다.

간단히 말해서 : 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문장, SyncRoot일부 ICollection 클래스 및 SyncRoot 디자인 패턴의 일부에 존재 하는 속성에 의해 영향을받는 것으로 보입니다 (이것은 나쁜 생각입니다)
   • C # 컨텍스트에 있기 때문에 VBish 명명을 원할지 확실하지 않습니다. 더 나쁜 것은 VB에서 변수 이름을 키워드와 동일하게 지정하는 것입니다. 이것이 혼란의 원인인지 확실하지 않습니다.

2. thisLock및 lockThisMSDN 문서에서 : C # 잠금 문 , VB의 SyncLock 문

   • 코드 샘플 : lock(thisLock) ,lock(lockThis)
   • 이것들이 예제를 위해 최소한으로 이름을 지 었는지 확실하지 않습니다
   • 우리가 이것을 static클래스 / 메서드 에서 사용한다면 이상합니다 .
   • 편집 : 잠금 에 대한 Wikipedia 기사 는 예제 에이 이름 지정을 사용합니다.

3. PadLock(다양한 케이스의) 여러 용도

   • 코드 샘플 : lock(PadLock) ,lock(padlock)
   • 나쁘지 않지만 내 유일한 쇠고기는 의심 할 여지 없이 추상 스레딩 개념 과 관련이없는 실제 "자물쇠" 의 이미지를 불러옵니다 .

4. 잠 그려는 의도에 따라 자물쇠 이름 지정

   • 코드 샘플 : lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • VB SyncRoot MSDN 페이지 예제 simpleMessageList에는 개인 messagesLock오브젝트 가있는 예제가 있습니다.
   • 변경하려는 구현 세부 사항이므로 잠그는 유형 ( "DictionaryLock")에 대해 잠금의 이름을 지정하는 것은 좋은 생각이 아닙니다. 잠그는 개념 / 개체 ( "messagesLock"또는 "commandQueueLock")의 이름을 선호합니다.
   • 흥미롭게도 코드 샘플의 온라인 또는 StackOverflow에서 객체를 잠그는이 명명 규칙은 거의 볼 수 없습니다 .

5. (EDIT) "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
    }
}

다른 리소스에 대해 여러 개의 잠금이있는 클래스를 얻은 후에이 습관을 겪었습니다. 따라서 액세스를 잠그는 리소스에 따라 잠금 개체의 이름을 지정합니다. 때로는 하나의 객체가 여러 리소스를 잠그는 경우가 있습니다.이 경우 이름을 어떤 식 으로든 존중하려고 시도하므로 독자는 "개별 리소스에 대한 다른 잠금도이 잠금과 충돌합니다"를 알고 있습니다.

나는 보통 그것을 호출 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과 같은 것은 단일 포트폴리오에는 적합하지만 적절한 프로젝트에는 실제로 의미 론적 이름을 사용해야 선언을 볼 때 코드를 검색하지 않고 객체가 실제로 무엇을하는지 알 수 있습니다.