Конвенція про найменування виділених предметів, що фіксують нитку [закрито]

Відносно незначне питання, але мені не вдалося знайти офіційну документацію або навіть думку / дискусії щодо цього блогу.

Простіше кажучи: коли я маю приватний об'єкт, єдиною метою якого є служіння приватному 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 класі / методі.
   • EDIT: Стаття Вікіпедії про блокування також використовує цю назву для свого прикладу

3. Кілька звичаїв PadLock(різного корпусу)

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

4. Іменування блокування на основі того, що він має намір заблокувати

   • Приклад коду: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • У прикладі сторінки VB SyncRoot MSDN він має simpleMessageListприклад із приватнимmessagesLock об'єктом
   • Я не думаю, що це гарна ідея називати замок проти типу, який ви замикаєте ("DictionaryLock"), оскільки це детальна інформація про реалізацію, яка може змінитися. Я вважаю за краще називати навколо поняття / об'єкта, який ви блокуєте ("messagesLock" або "commandQueueLock")
   • Цікаво, що я дуже рідко бачу цю умову іменування для блокування об'єктів у зразках коду в Інтернеті або на StackOverflow.

5. (EDIT) Специфікація 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" також знайде такі речі, як "годинник".

Такі речі, як lockThis та Padlock, добре підходять для портфоліо uni, але для правильних проектів ви повинні реально використовувати семантичні назви, щоб при перегляді декларацій ви знали, що об'єкт насправді робить, не шукаючи код.