Konwencja nazewnictwa dla obiektów dedykowanych do blokowania wątków [zamknięte]

Stosunkowo niewielkie pytanie, ale nie udało mi się znaleźć oficjalnej dokumentacji ani nawet opinii na blogu / dyskusji na jej temat.

Mówiąc wprost: kiedy mam prywatny obiekt, którego jedynym celem jest służenie prywatnemu lock , jak mam nazwać ten obiekt?

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

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

Co powinniśmy LockingObjecttu wymienić ? Weź również pod uwagę nie tylko nazwę zmiennej, ale także jej wygląd w kodzie podczas blokowania.

Widziałem różne przykłady, ale pozornie nie ma solidnej porady:

1. Wiele zastosowań SyncRoot(i odmian, takich jak_syncRoot ).

   • Przykładowy kod: lock(SyncRoot) ,lock(_syncRoot)
   • Wydaje się, że na to ma wpływ równoważne SyncLockoświadczenie VB ,SyncRoot właściwość istniejąca w niektórych klasach ICollection i część pewnego rodzaju wzorca projektowego SyncRoot (co jest prawdopodobnie złym pomysłem)
   • Będąc w kontekście C #, nie jestem pewien, czy chciałbym mieć nazwę VBish. Co gorsza, w języku VB nazwa zmiennej jest taka sama jak słowa kluczowego. Nie jestem pewien, czy byłoby to źródłem zamieszania, czy nie.

2. thisLocki lockThisod artykułów MSDN: C # Blokada komunikat , komunikat VB SyncLock

   • Przykładowy kod: lock(thisLock) ,lock(lockThis)
   • Nie jestem pewien, czy zostały one nazwane minimalnie wyłącznie dla przykładu, czy nie
   • To trochę dziwne, jeśli używamy tego w ciągu static klasie / metodzie.
   • EDYCJA: Artykuł Wikipedii na temat zamków również używa tego nazewnictwa na swój przykład

3. Kilka zastosowań PadLock(o różnej obudowie)

   • Przykładowy kod: lock(PadLock) ,lock(padlock)
   • Nieźle, ale moją jedyną wołowiną jest to, że nic dziwnego, że przywołuje obraz fizycznej „kłódki”, której nie kojarzę z abstrakcyjną koncepcją wątków .

4. Nazywanie blokady na podstawie tego, co zamierza zablokować

   • Przykładowy kod: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • Na przykład strona VB SyncRoot MSDN, ma simpleMessageListprzykład z prywatnym messagesLockobiekcie
   • Nie sądzę, że dobrym pomysłem jest nazwać blokadę typem, który blokujesz („DictionaryLock”), ponieważ jest to szczegół implementacji, który może się zmienić. Wolę nazewnictwo wokół koncepcji / obiektu, który blokujesz („messagesLock” lub „commandQueueLock”)
   • Co ciekawe, bardzo rzadko widzę tę konwencję nazewnictwa do blokowania obiektów w próbkach kodu online lub na StackOverflow.

5. (EDYCJA) Specyfikacja C # w sekcji „8.12 Instrukcja blokady” zawiera przykład tego wzorca i nazywa go synchronizationObject

   • Przykładowy kod: lock(SynchronizationObject) ,lock(synchronizationObject)

Pytanie: Jakie jest Twoje ogólne zdanie na temat nazewnictwa prywatnych obiektów blokujących?

Ostatnio zacząłem nazywać je ThreadLock(tak jakby opcja 3), ale zaczynam kwestionować tę nazwę.

Często używam tego wzoru blokowania (w powyższym przykładzie kodu) we wszystkich aplikacjach, więc pomyślałem, że sensowniej byłoby uzyskać bardziej profesjonalną opinię / dyskusję na temat solidnej konwencji nazewnictwa dla nich. Dzięki!

Przyzwyczaiłem się nazywać go SomeResourceLocktam , gdzie SomeResourcepotrzebujesz blokady, aby uzyskać dostęp / aktualizację, tj. (Wybacz wszelkie problemy z wątkami, to tylko ilustracja)

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
    }
}

Przyzwyczaiłem się do tego po zajęciach, w których mogę mieć wiele blokad dla różnych zasobów, więc nazywam obiekt blokujący na podstawie tego, do jakich zasobów ma dostęp blokujący. Czasami jeden obiekt może blokować wiele zasobów, w którym to przypadku staram się, aby nazwy w jakiś sposób szanowały to, aby czytelnik wiedział, że „inne blokady dla tych pojedynczych zasobów również będą sprzeczne z tą blokadą”.

Zwykle nazywam to locker, ale ponieważ jest prywatny, uważam, że jest to nieco nieistotny szczegół implementacji. Pierwsza zasada: używaj standardów swojego zespołu / firmy. Jeśli nie ma, cóż, proszę, zrób jeden i użyj go, ale czyniąc to, zachowaj prostotę. Jeśli twoja klasa ma pojedynczy obiekt blokujący, wywołanie go foojest wystarczająco dobre. Jeśli masz ich wiele, dobrym porządkiem biznesu może być po prostu przegląd projektu tej klasy, aby sprawdzić, czy robi zbyt wiele różnych rzeczy. Ale jeśli nie, nazwa staje się ważna, jak w tym całkowicie wymyślonym przykładzie:

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...
            }
        }
    }
}

Zawsze używałem lck_. W ten sposób, jeśli ctrl + f 'lck', powinieneś tylko znaleźć zamki, podczas gdy „lock” również znajdzie takie rzeczy jak „clock”.

Takie rzeczy, jak lockThis i Padlock są odpowiednie dla portfeli uni, ale do odpowiednich projektów powinieneś naprawdę używać nazw semantycznych, aby patrząc na deklaracje, wiedziałeś, co faktycznie robi obiekt bez przeszukiwania kodu.