Convenzione di denominazione per oggetti di bloccaggio del filo dedicati [chiuso]

Question

Convenzione di denominazione per oggetti di bloccaggio del filo dedicati [chiuso]

#1 da (5 voti)
#2 da (3 voti)
#3 da (2 voti)

14

Una domanda relativamente minore, ma non sono stato in grado di trovare la documentazione ufficiale o persino le opinioni / discussioni del blog su di esso.

In parole povere: quando ho un oggetto privato il cui unico scopo è di servire% privato% co_de, come faccio a nominare quell'oggetto?

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

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

Che cosa dovremmo chiamare lock qui? Considera anche non solo il nome della variabile, ma come appare nel codice quando si blocca.

Ho visto vari esempi, ma apparentemente nessun consiglio concreto:

Molti usi di LockingObject (e variazioni come SyncRoot ).
- Esempio di codice: _syncRoot , lock(SyncRoot)
- Questo sembra essere influenzato dall'equivalente lock(_syncRoot) di VB, la proprietà SyncLock che esiste su alcune classi di ICollection e parte di un qualche tipo di pattern di progettazione di SyncRoot (che è probabilmente una cattiva idea)
- Essere in un contesto C #, non sono sicuro se vorrei avere una denominazione VBish. Ancora peggio, in VB la variabile è la stessa della parola chiave. Non sono sicuro se ciò possa essere fonte di confusione o meno.
SyncRoot e thisLock dagli articoli MSDN: Dichiarazione di blocco C # , < a href="http://msdn.microsoft.com/en-us/library/3a86s51t.aspx"> VB SyncLock Statement
- Esempio di codice: lockThis , lock(thisLock)
- Non sono sicuro se questi siano stati nominati in modo minimamente puramente per l'esempio o meno
- Un po 'strano se lo usiamo in una classe / metodo lock(lockThis) .
- EDIT: l'articolo di Wikipedia sui blocchi utilizza anche questa denominazione per il suo esempio
Diversi usi di static (di varianti di involucro)
- Esempio di codice: PadLock , lock(PadLock)
- Non male, ma il mio unico problema è che non sorprende invocare l'immagine di un lucchetto fisico "che tendo a non associare al concetto di threading astratto .
Denominare il blocco in base a ciò che intende bloccare
- Esempio di codice: lock(padlock) , lock(messagesLock) , lock(DictionaryLock)
- Nell'esempio della pagina MSDN SyncRoot VB, ha un esempio di lock(commandQueueLock) con un oggetto simpleMessageList privato
- Non penso che sia una buona idea denominare il blocco rispetto al tipo che stai bloccando ("DictionaryLock") in quanto è un dettaglio di implementazione che potrebbe cambiare. Preferisco dare un nome al concetto / oggetto che stai bloccando ("messagesLock" o "commandQueueLock")
- È interessante notare che molto raramente vedere questa convenzione di denominazione per bloccare gli oggetti negli esempi di codice online o su StackOverflow.
(EDIT) Le specifiche C # nella sezione "8.12 L'istruzione Lock" ha un esempio di questo pattern e lo nomina messagesLock
- Esempio di codice: synchronizationObject , lock(SynchronizationObject)

Domanda: Qual è la tua opinione generalmente sul nominare private oggetti di blocco?

Recentemente, ho iniziato a chiamarli lock(synchronizationObject) (quindi mi piace l'opzione 3), ma mi sto ritrovando 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 avuto senso avere un'opinione / discussione più professionale su una solida convenzione di denominazione per loro. Grazie!

c# naming multithreading vb.net

posta Chris Sinclair 10.10.2012 - 17:33

fonte

3 risposte

5

Di solito lo chiamo locker , ma poiché è privato, credo che sia un dettaglio di implementazione un po 'trascurabile. Prima regola empirica, usa gli standard della tua squadra / azienda. Se non ce n'è uno, beh, per favore 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 commerciale potrebbe semplicemente rivisitare il design di quella classe per vedere se sta facendo troppe cose diverse. Ma, se no, allora il nome diventa importante, come in questo esempio completamente forzato:

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

risposta data 10.10.2012 - 18:30

fonte

2

Ho sempre usato lck_. In questo modo se ctrl + f 'lck' allora dovresti trovare solo i blocchi mentre 'lock' troverà anche cose come 'clock'.

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

risposta data 10.10.2012 - 18:28

fonte

Leggi altre domande sui tag c# naming multithreading vb.net

Quando una radice di aggregazione dovrebbe contenere un'altra AR (e quando non dovrebbe) Come abilitare correttamente la licenza del software open source

score 3 · Accepted Answer

Ho preso l'abitudine di chiamarlo SomeResourceLock dove SomeResource è ciò che ti serve per accedere al blocco / aggiornamento, ad esempio (perdona qualsiasi problema relativo ai 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
    }
}

Mi sono imbattuto in questa abitudine dopo avere classi in cui potrei avere più blocchi per risorse diverse, quindi chiamo l'oggetto di blocco in base alle risorse a cui sta bloccando l'accesso. A volte un oggetto può bloccare più risorse, nel qual caso proverei a rispettare i nomi in qualche modo, quindi il lettore sa "altri blocchi per quelle risorse individuali saranno in conflitto con questo blocco".