Özel İş Parçacığı Kilitleme nesneleri için Adlandırma Kuralı [kapalı]


16

Nispeten ufak bir soru, ancak resmi belgeler bulamadım, hatta blog görüşlerini / tartışmalarını bulamadım.

Basitçe söylemek gerekirse: Tek amacı özel hizmet vermek olan özel bir nesnem olduğunda lock, bu nesneye ne ad verebilirim ?

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

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

LockingObjectBurada ne isimlendirmeliyiz ? Ayrıca sadece değişkenin adını değil, aynı zamanda kilitleme sırasında nasıl kod içinde göründüğünü de göz önünde bulundurun.

Çeşitli örnekler gördüm, ancak görünüşe göre sağlam bir tavsiye yok:

  1. Bol kullanımları SyncRoot(ve varyasyonları gibi _syncRoot).

    • Kod örnek: lock(SyncRoot) ,lock(_syncRoot)
    • Bu, VB'nin eşdeğer SyncLockifadesinden, SyncRootbazı ICollection sınıflarında bulunan mülkten ve bir çeşit SyncRoot tasarım modelinin (muhtemelen kötü bir fikirdir) bir parçasından etkileniyor gibi görünüyor.
    • Bir C # bağlamda olmak, bir VBish adlandırma istiyorum emin değilim. Daha da kötüsü, VB'de değişkeni anahtar kelimeyle aynı adlandırırken. Bunun bir karışıklık kaynağı olup olmayacağından emin değilim.
  2. thisLockve lockThisMSDN makalelerinden: C # lock Bildirimi , VB SyncLock Bildirimi

    • Kod örnek: lock(thisLock) ,lock(lockThis)
    • Bunların yalnızca örnek için minimal olarak adlandırılıp adlandırılmadığından emin değilim
    • Bunu bir staticsınıf / yöntem içinde kullanıyor olmamız biraz garip .
    • EDIT: Kilitler Wikipedia makalesinde örneği için bu adlandırma kullanır
  3. Çeşitli kullanımlar PadLock(değişen kasa)

    • Kod örnek: lock(PadLock) ,lock(padlock)
    • Fena değil, ama benim tek sığır eti şaşırtıcı bir şekilde soyut diş açma konsepti ile ilişkilendirmek eğilimindedir fiziksel bir "asma kilit" imajını çağırıyor .
  4. Kilidi, neyi kilitlemek istediklerine göre adlandırma

    • Kod örnek: lock(messagesLock) , lock(DictionaryLock),lock(commandQueueLock)
    • VB SyncRoot MSDN sayfası örneğinde, simpleMessageListözel messagesLocknesne içeren bir örneği var
    • Değişebilir bir uygulama detayı olduğu için kilitlediğiniz tipe ("DictionaryLock") karşı kilidi adlandırmak iyi bir fikir olduğunu sanmıyorum. Kilitlemekte olduğunuz kavramın / nesnenin etrafında adlandırmayı tercih ederim ("messagesLock" veya "commandQueueLock")
    • İlginç bir şekilde, çok nadiren çevrimiçi veya StackOverflow kod örneklerinde nesneleri kilitlemek için bu adlandırma kuralını görüyorum.
  5. (EDIT) "8.12 Kilit İfadesi" bölümündeki C # spesifikasyonu bu kalıba bir örnek veriyor ve ismini veriyor synchronizationObject

    • Kod örnek: lock(SynchronizationObject) ,lock(synchronizationObject)

Soru: Genel olarak özel kilitleme nesnelerini adlandırmak hakkında ne düşünüyorsunuz ?

Son zamanlarda, onları adlandırmaya başladım ThreadLock(seçenek 3 gibi), ama kendimi bu ismi sorgularken buluyorum.

Uygulamalarım boyunca bu kilitleme desenini (yukarıda verilen kod örneğinde) sık sık kullanıyorum, bu yüzden onlar için sağlam bir adlandırma kuralı hakkında daha profesyonel bir fikir / tartışma almanın mantıklı olabileceğini düşündüm. Teşekkürler!

Yanıtlar:


4

Bunu, arama alışkanlığı için atmış SomeResourceLocknereye SomeResourcesen yani erişim / güncelleme kilidi gerekenler (herhangi bir konu sorunlarını affet, bu sadece bir örnektir)

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

Ben farklı kaynaklar için birden fazla kilit olabilir sınıfları yaptıktan sonra bu alışkanlık üzerine geldim, bu yüzden kilitleme nesnesini hangi kaynaklara erişim kilitleme dayalı olarak adlandırın. Bazen bir nesne birden fazla kaynağı kilitliyor olabilir, bu durumda isimleri bir şekilde saygı duymaya çalışacağım, bu yüzden okuyucu "bu kaynaklar için diğer kilitlerin de bu kilitle tartışacağını" biliyor.


2
Bence bu kafa karıştırıcı, çünkü SynchronizationContextoldukça farklı bir şey.
svick

1
@svick Tamamen mümkün terimi terimini yanlış kullanıyorum, hala kilitli olan kaynak hakkında spesifik olmanın önemli olduğunu düşünüyorum, ancak daha mantıklıysa, "SynchronizationContext" yerine "Lock" kelimesini önermek için bunu düzenleyeceğim.
Jimmy Hoffa

6

Ben genellikle onu ararım locker, ancak özel olduğu için, bunun önemsiz bir uygulama detayı olduğuna inanıyorum. İlk kural, ekibinizin / şirketinizin standartlarını kullanın. Bir tane yoksa, lütfen bir tane yapın ve kullanın, ancak bunu yaparken, işleri basit tutun. Sınıfınızda tek bir kilitleme nesnesi varsa, çağırmak fooyeterince iyidir. Çok fazla varsa, iyi bir iş düzeni, çok fazla farklı şeyler yapıp yapmadığını görmek için önce o sınıfın tasarımını tekrar gözden geçiriyor olabilir. Ancak, değilse, bu tamamen çelişkili örnekte olduğu gibi ad önemli hale gelir:

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

2
Birden fazla kilitleme mekanizması için aşağı yukarı böyle bir adlandırma stiline tamamen katılıyorum. İki dolaplı bir sınıf uyguladığımda da bu stile çok benzeyen bir şey vardı (daha sonra yeniden
Chris Sinclair

2

Her zaman lck_ kullandım. Bu şekilde ctrl + f 'lck' tuşuna basarsanız, sadece 'kilit' de 'saat' gibi şeyler bulurken kilitleri bulmalısınız.

LockThis ve Padlock gibi şeyler uni portföyler için iyidir, ancak uygun projeler için anlamsal isimler kullanmalısınız, böylece bildirimlere baktığınızda nesnenin kodda arama yapmadan ne yaptığını bilirsiniz.


Kısa isim biçimlerine meraklı değilim. Bir yandan, tüm kullanımları bulmak için benzersiz (ish) bir adlandırma stiline sahip olmak mantıklıdır. Öte yandan, belki de şanslıydım, kilit bulmaya ihtiyacım olmadı; "Kilit (" için arama yapmak zorunda kalacağımı hayal edersem, kolayca görmezden gelmek için yeterli sayıda yanlış pozitifle bana yeterince iyi bir sonuç verir.
Chris Sinclair
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.