Convenzione di denominazione per oggetti di thread thread dedicati [chiuso]

Una domanda relativamente minore, ma non sono stato in grado di trovare documentazione ufficiale o opinioni o discussioni sul blog.

In parole povere: quando ho un oggetto privato il cui unico scopo è quello di servire come privato lock, come posso chiamarlo?

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

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

Come dovremmo nominare LockingObjectqui? Considera anche non solo il nome della variabile ma come appare nel codice durante il blocco.

Ho visto vari esempi, ma apparentemente non ci sono solidi consigli da seguire:

1. Un sacco di usi di SyncRoot(e variazioni come _syncRoot).

   • Codice di esempio: lock(SyncRoot) ,lock(_syncRoot)
   • Ciò sembra essere influenzato dall'affermazione equivalente di VB SyncLock, la SyncRootproprietà che esiste su alcune classi ICollection e parte di un qualche tipo di modello di progettazione SyncRoot (che probabilmente è una cattiva idea)
   • Essere in un contesto C #, non sono sicuro se vorrei avere un nome VBish. Ancora peggio, in VB la variabile è uguale alla parola chiave. Non sono sicuro se questo sarebbe una fonte di confusione o meno.

2. thisLocke lockThisdagli articoli MSDN: C # lock Statement , VB SyncLock Statement

   • Codice di esempio: lock(thisLock) ,lock(lockThis)
   • Non sono sicuro se questi sono stati nominati minimamente puramente per l'esempio o meno
   • Un po 'strano se lo stiamo usando in una staticclasse / metodo.
   • EDIT: L'articolo di Wikipedia sui blocchi usa anche questa denominazione per il suo esempio

3. Diversi usi di PadLock(di involucro variabile)

   • Codice di esempio: lock(PadLock) ,lock(padlock)
   • Non male, ma il mio unico manzo è che non sorprende che invochi l'immagine di un "lucchetto" fisico che tendo a non associare al concetto astratto di threading .

4. Assegnare un nome al blocco in base a ciò che intende bloccare

   • Codice di esempio: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
   • Nell'esempio di pagina MSDN VB SyncRoot, ha un simpleMessageListesempio con un messagesLockoggetto privato
   • Non credo sia una buona idea nominare il blocco in base al tipo che stai bloccando ("DictionaryLock") in quanto è un dettaglio dell'implementazione che può cambiare. Preferisco dare un nome al concetto / oggetto che stai bloccando ("messageLock" o "commandQueueLock")
   • È interessante notare che raramente vedo questa convenzione di denominazione per bloccare oggetti negli esempi di codice online o su StackOverflow.

5. (EDIT) Le specifiche C # nella sezione "8.12 The Lock Statement" hanno un esempio di questo modello e lo nominano synchronizationObject

   • Codice di esempio: lock(SynchronizationObject) ,lock(synchronizationObject)

Domanda: Qual è la tua opinione in generale sulla denominazione degli oggetti di blocco privati ?

Di recente, ho iniziato a nominarli ThreadLock(in modo un po 'come l'opzione 3), ma mi ritrovo a mettere in discussione quel nome.

Uso frequentemente questo modello di blocco (nell'esempio di codice fornito sopra) in tutte le mie applicazioni, quindi ho pensato che avrebbe senso avere un'opinione / discussione più professionale su una solida convenzione di denominazione per loro. Grazie!

Ho preso l'abitudine di chiamarlo SomeResourceLockdove SomeResourceè quello che ti serve per bloccare / aggiornare, cioè (perdona qualsiasi problema di thread, questa è solo un'illustrazione)

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

Ho preso questa abitudine dopo aver avuto classi in cui potrei avere più blocchi per risorse diverse, quindi nomina l'oggetto di blocco in base alle risorse a cui sta bloccando l'accesso. A volte un oggetto potrebbe bloccare più risorse, nel qual caso proverei a far rispettare i nomi in qualche modo, quindi il lettore sa che "altri blocchi per quelle singole risorse saranno in conflitto con questo blocco".

Di solito lo chiamo locker, ma dal momento che è privato, credo che sia un dettaglio di implementazione un po 'irrilevante. Prima regola empirica, usa gli standard della tua squadra / azienda. Se non ce n'è uno, beh, creane uno e usalo, ma nel farlo, mantieni le cose semplici. Se la tua classe ha un singolo oggetto di blocco, chiamarlo fooè abbastanza buono. Se ne hai molti, un buon ordine di attività potrebbe semplicemente rivisitare il design di quella classe per vedere se sta facendo troppe cose diverse. Ma, in caso contrario, il nome diventa importante, come in questo esempio completamente inventato:

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

Ho sempre usato lck_. In questo modo se premi Ctrl + F 'lck' dovresti trovare solo i blocchi mentre 'lock' troverà anche cose come 'orologio'.

Cose come lockThis e Padlock vanno bene per i portafogli uni ma per progetti adeguati dovresti davvero usare nomi semantici in modo che quando guardi le dichiarazioni sai cosa fa realmente l'oggetto senza cercare nel codice.