Соглашение об именовании объектов для блокировки выделенных потоков [закрыто]

Относительно незначительный вопрос, но я не смог найти официальную документацию или даже мнение / обсуждение в блоге.

Проще говоря: когда у меня есть частный объект, единственная цель которого - служить частному лицу lock, как я называю этот объект?

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

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

Что мы должны назвать LockingObjectздесь? Также учитывайте не только имя переменной, но и то, как она выглядит в коде при блокировке.

Я видел различные примеры, но, казалось бы, нет твердых советов:

1. Много использования SyncRoot(и варианты, такие как _syncRoot).

   • Пример кода: lock(SyncRoot) ,lock(_syncRoot)
   • Похоже, на это влияет эквивалентное SyncLockутверждение VB , SyncRootсвойство, которое существует в некоторых классах ICollection и часть некоторого шаблона проектирования SyncRoot (что, возможно, является плохой идеей)
   • Находясь в контексте C #, не уверен, хочу ли я иметь именование VBish. Хуже того, в VB именование переменной совпадает с ключевым словом. Не уверен, если это будет источником путаницы или нет.

2. thisLockи lockThisиз статей MSDN: оператор блокировки C # , оператор VB SyncLock

   • Пример кода: lock(thisLock) ,lock(lockThis)
   • Не уверен, были ли они названы минимально чисто для примера или нет
   • Довольно странно, если мы используем это в staticклассе / методе.
   • РЕДАКТИРОВАТЬ: статья Википедии о замках также использует это наименование в качестве примера

3. Несколько использования PadLock(различного кожуха)

   • Пример кода: lock(PadLock) ,lock(padlock)
   • Неплохо, но мой единственный недостаток в том, что он неудивительно вызывает образ физического «замка», который я склонен не ассоциировать с концепцией абстрактного потока .

4. Называя блокировку, основываясь на том, что она собирается заблокировать

   • Пример кода: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • В примере страницы MSDN VB SyncRoot у него есть simpleMessageListпример с закрытым messagesLockобъектом
   • Я не думаю, что будет хорошей идеей называть блокировку для типа, который вы блокируете ("DictionaryLock"), так как это может быть изменено в деталях реализации. Я предпочитаю именовать концепцию / объект, который вы блокируете ("messagesLock" или "commandQueueLock")
   • Интересно, что я очень редко вижу это соглашение об именах для блокировки объектов в примерах кода онлайн или в StackOverflow.

5. (РЕДАКТИРОВАТЬ) Спецификация C # в разделе "8.12 Оператор блокировки" имеет пример этого шаблона и называет его 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, хороши для универсальных портфелей, но для правильных проектов вам действительно следует использовать семантические имена, чтобы при взгляде на объявления вы знали, что на самом деле делает объект, не просматривая код.