.NET'te çift denetimli kilitlemede uçucu değiştirici ihtiyacı

Birden çok metin, .NET'te çift denetimli kilitlemeyi uygularken kilitlediğiniz alana geçici değiştiricinin uygulanmış olması gerektiğini söyler. Ama neden tam olarak? Aşağıdaki örneği ele alarak:

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

neden "kilitlemek (syncRoot)" gerekli bellek tutarlılığını sağlamıyor? "Kilit" ifadesinden sonra hem okuma hem de yazmanın uçucu olacağı ve böylece gerekli tutarlılığın sağlanacağı doğru değil mi?

Uçucu gereksizdir. İyi sıralama**

volatiledeğişken üzerindeki okuma ve yazma işlemleri arasında bir bellek engeli * oluşturmak için kullanılır.
lock, kullanıldığında, bloğa lockerişimi bir iş parçacığıyla sınırlandırmanın yanı sıra, içindeki bloğun çevresinde bellek engellerinin oluşturulmasına neden olur .
Bellek engelleri, her iş parçacığının değişkenin en güncel değerini (bazı kayıtlarda önbelleğe alınan yerel bir değeri değil) okumasını ve derleyicinin ifadeleri yeniden sıralamamasını sağlar. Kullanmak volatilegereksiz ** çünkü zaten bir kilidiniz var.

Joseph Albahari bu konuyu benim yapabileceğimden çok daha iyi açıklıyor.

Ve Jon Skeet'in singleton'u C # 'ta uygulama kılavuzuna göz atmayı unutmayın

update :
* volatiledeğişkenin VolatileReads olmasına neden olur VolatileWriteve CLR üzerindeki x86 ve x64 üzerinde bir MemoryBarrier. Diğer sistemlerde daha ince taneli olabilirler.

** Cevabım yalnızca CLR'yi x86 ve x64 işlemcilerde kullanıyorsanız doğrudur. Bu olabilir Mono (ve diğer uygulamaları), Itanium64 ve gelecekteki donanım üzerinde olduğu gibi, diğer bellek modellerinde gerçek olamayacak. Bu, Jon'un çift kontrollü kilitleme için "gotchas" makalesinde bahsettiği şeydir.

Kodun zayıf bir bellek modeli durumunda düzgün çalışması için {değişkeni işaretlemek, volatileonunla okumak Thread.VolatileReadveya bir çağrı eklemek Thread.MemoryBarrier} işlemlerinden birini yapmak gerekli olabilir.

Anladığım kadarıyla, CLR'de (IA64'te bile), yazılar asla yeniden sıralanmıyor (yazılar her zaman yayın anlamlarına sahiptir). Bununla birlikte, IA64'te, değişken olarak işaretlenmedikçe, okumalar yazma işlemlerinden önce gelecek şekilde yeniden sıralanabilir. Ne yazık ki, oynamak için IA64 donanımına erişimim yok, bu yüzden bu konuda söyleyeceğim her şey spekülasyon olurdu.

Bu makaleleri de yararlı buldum:
http://www.codeproject.com/KB/tips/MemoryBarrier.aspx
vance morrison'un makalesi (buna her şey bağlantılıdır, iki kez kontrol edilmiş kilitlemeden
bahseder ) chris brumme'nin makalesi (her şey buna bağlantılıdır) )
Joe Duffy: Çift Kontrollü Kilitlemenin Kırık Çeşitleri

luis abreu'nun multithreading serisi, kavramlara da güzel bir genel bakış sağlar
http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-load-and-store-reordering.aspx
http: // msmvps. com / bloglar / luisabreu / arşiv / 2009/07/03 / multithreading-tanıtım-bellek-çitleri.aspx

volatileAlan olmadan uygulamanın bir yolu var . Açıklayacağım ...

Bence tehlikeli olan, kilidin dışında tamamen başlatılmamış bir örneği elde edebilmeniz için, kilit içinde bellek erişiminin yeniden sıralanmasıdır. Bundan kaçınmak için şunu yapıyorum:

public sealed class Singleton
{
   private static Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         // very fast test, without implicit memory barriers or locks
         if (instance == null)
         {
            lock (syncRoot)
            {
               if (instance == null)
               {
                    var temp = new Singleton();

                    // ensures that the instance is well initialized,
                    // and only then, it assigns the static variable.
                    System.Threading.Thread.MemoryBarrier();
                    instance = temp;
               }
            }
         }

         return instance;
      }
   }
}

Kodu anlamak

Singleton sınıfının yapıcısının içinde bazı başlatma kodlarının olduğunu hayal edin. Alan yeni nesnenin adresiyle ayarlandıktan sonra bu talimatlar yeniden sıralanırsa, tamamlanmamış bir örneğiniz var ... Sınıfın şu koda sahip olduğunu hayal edin:

private int _value;
public int Value { get { return this._value; } }

private Singleton()
{
    this._value = 1;
}

Şimdi yeni operatörü kullanarak kurucuya bir çağrı hayal edin:

instance = new Singleton();

Bu, şu işlemlere genişletilebilir:

ptr = allocate memory for Singleton;
set ptr._value to 1;
set Singleton.instance to ptr;

Ya bu talimatları şu şekilde yeniden sıralarsam:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
set ptr._value to 1;

Bir fark yaratır mı? Tek bir iş parçacığı düşünüyorsanız HAYIR . EVET Eğer birden fazla iş parçacığı düşünüyorsanız ... ya iş parçacığı hemen sonra kesilirse set instance to ptr:

ptr = allocate memory for Singleton;
set Singleton.instance to ptr;
-- thread interruped here, this can happen inside a lock --
set ptr._value to 1; -- Singleton.instance is not completelly initialized

Bellek erişiminin yeniden düzenlenmesine izin vermeyerek bellek engelinin önlediği şey budur:

ptr = allocate memory for Singleton;
set temp to ptr; // temp is a local variable (that is important)
set ptr._value to 1;
-- memory barrier... cannot reorder writes after this point, or reads before it --
-- Singleton.instance is still null --
set Singleton.instance to temp;

Mutlu kodlamalar!

Kimsenin soruyu gerçekten yanıtladığını sanmıyorum , bu yüzden bir deneyeceğim.

Uçucu ve ilk if (instance == null)"gerekli" değildir. Kilit, bu kodu iş parçacığı için güvenli hale getirecektir.

Öyleyse soru şu: neden ilkini eklersiniz if (instance == null)?

Bunun nedeni muhtemelen kodun kilitli bölümünü gereksiz yere yürütmekten kaçınmaktır. Kilidin içindeki kodu çalıştırırken, bu kodu da yürütmeye çalışan diğer herhangi bir iş parçacığı engellenir, bu da birçok iş parçacığından sık sık singleton'a erişmeye çalışırsanız programınızı yavaşlatır. Dile / platforma bağlı olarak, kilidin kendisinden kaçınmak isteyebileceğiniz genel giderler de olabilir.

Bu nedenle, kilide ihtiyacınız olup olmadığını görmenin gerçekten hızlı bir yolu olarak ilk sıfır kontrolü eklenir. Tekli oluşturmanıza gerek yoksa, kilidi tamamen önleyebilirsiniz.

Ancak, referansın bir şekilde kilitlemeden boş olup olmadığını kontrol edemezsiniz, çünkü işlemci önbelleğe alma nedeniyle başka bir iş parçacığı onu değiştirebilir ve gereksiz yere kilide girmenize neden olacak "eski" bir değer okuyabilirsiniz. Ama kilitlenmekten kaçınmaya çalışıyorsun!

Böylece, kilit kullanmaya gerek kalmadan en son değeri okumanızı sağlamak için tekliyi uçucu hale getirirsiniz.

Yine de iç kilide ihtiyacınız var çünkü volatile yalnızca değişkene tek bir erişim sırasında sizi korur - bir kilit kullanmadan güvenli bir şekilde test edip ayarlayamazsınız.

Şimdi, bu gerçekten faydalı mı?

Pekala, "çoğu durumda hayır" derdim.

Singleton.Instance kilitler nedeniyle verimsizliğe neden olabiliyorsa, o zaman neden bu kadar sık ​​çağırıyorsunuz ki bu önemli bir sorun olur ? Bir singletonun tüm amacı, yalnızca bir tane olmasıdır, böylece kodunuz singleton referansını bir kez okuyabilir ve önbelleğe alabilir.

Bu önbelleğe almanın nerede mümkün olmayacağını düşünebildiğim tek durum, çok sayıda iş parçacığına sahip olduğunuzda olabilir (örneğin, her isteği işlemek için yeni bir iş parçacığı kullanan bir sunucu, her biri çok kısa çalışan milyonlarca iş parçacığı oluşturuyor olabilir) Singleton.Instance'ı bir kez çağırmak zorunda kalacaktı).

Bu yüzden, çifte kontrollü kilitlemenin performans açısından kritik çok özel durumlarda gerçek bir yeri olan bir mekanizma olduğundan şüpheleniyorum ve sonra herkes gerçekten ne yaptığını ve yapıp yapmadığını düşünmeden "bunu yapmanın doğru yolu bu" ana vagonuna takıldı. aslında kullanmaları durumunda gerekli olacaktır.

Çift kontrol kilidi deseni ile uçucu kullanmalısınız.

Çoğu kişi bu makaleyi, uçucuya ihtiyacınız olmadığının kanıtı olarak gösteriyor: https://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10

Ancak sonuna kadar okuyamıyorlar: " Son Bir Uyarı Sözü - Sadece x86 bellek modelinde mevcut işlemcilerde gözlemlenen davranıştan tahmin ediyorum. Bu nedenle düşük kilit teknikleri de kırılgandır çünkü donanım ve derleyiciler zaman içinde daha agresifleşebilir. . Bu kırılganlığın kodunuz üzerindeki etkisini en aza indirmek için bazı stratejiler. İlk olarak, mümkün olduğunda düşük kilit tekniklerinden kaçının. (...) Son olarak, örtük garantilere güvenmek yerine geçici bildirimler kullanarak mümkün olan en zayıf bellek modelini varsayın. . "

Daha ikna etmeye ihtiyacınız varsa, ECMA spesifikasyonundaki bu makaleyi okuyun diğer platformlar için kullanılacaktır: msdn.microsoft.com/en-us/magazine/jj863136.aspx

Daha fazla ikna etmeye ihtiyacınız varsa, bu yeni makaleyi, geçici olmadan çalışmasını engelleyen optimizasyonların konulabileceğini okuyun: msdn.microsoft.com/en-us/magazine/jj883956.aspx

Özetle, şu an için geçici olmadan sizin için "işe yarayabilir", ancak uygun kod yazma şansına sahip olun ve ya uçucu ya da uçucu / yazım yöntemlerini kullanın. Aksi şekilde yapılmasını öneren makaleler, bazen kodunuzu etkileyebilecek JIT / derleyici optimizasyonlarının bazı olası risklerini ve ayrıca kodunuzu bozabilecek gelecekteki optimizasyonları dışarıda bırakıyor. Ayrıca, son makalede bahsedilen varsayımlar gibi, değişken olmadan çalışmanın önceki varsayımları zaten ARM üzerinde geçerli olmayabilir.

AFAIK (ve - bunu dikkatli bir şekilde al, aynı anda pek çok şey yapmıyorum) hayır. Kilit size birden fazla yarışmacı (konu) arasında senkronizasyon sağlar.

Öte yandan volatile, makinenize değeri her seferinde yeniden değerlendirmesini söyler, böylece önbelleğe alınmış (ve yanlış) bir değere rastlamazsınız.

Http://msdn.microsoft.com/en-us/library/ms998558.aspx sayfasına bakın ve aşağıdaki alıntıya dikkat edin:

Ayrıca, değişkene erişilmeden önce örnek değişkenine atamanın tamamlanmasını sağlamak için değişkenin geçici olduğu bildirilir.

Uçucu bir açıklama: http://msdn.microsoft.com/en-us/library/x13ttww7%28VS.71%29.aspx

Sanırım aradığımı buldum. Ayrıntılar bu makalededir - http://msdn.microsoft.com/en-us/magazine/cc163715.aspx#S10 .

Özetlemek gerekirse - .NET'te uçucu değiştiriciye gerçekten de bu durumda gerek yoktur. Ancak daha zayıf bellek modellerinde, tembel olarak başlatılan nesnenin yapıcısında yapılan yazmalar, alana yazıldıktan sonra gecikebilir, bu nedenle diğer evreler, ilk if ifadesinde bozuk boş olmayan örneği okuyabilir.

lockYeterlidir. MS dil spesifikasyonunun (3.0) kendisi §8.12'de bu kesin senaryodan bahsedilmeksizin şunlardan bahsedilmeden bahseder volatile:

Daha iyi bir yaklaşım, özel bir statik nesneyi kilitleyerek statik verilere erişimi senkronize etmektir. Örneğin:

class Cache
{
    private static object synchronizationObject = new object();
    public static void Add(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
    public static void Remove(object x) {
        lock (Cache.synchronizationObject) {
          ...
        }
    }
}

Bu, çift kontrol edilmiş kilitleme ile uçucu kullanma hakkında oldukça iyi bir gönderi:

http://tech.puredanger.com/2007/06/15/double-checked-locking/

Java'da amaç bir değişkeni korumaksa, değişken olarak işaretlenmişse kilitlemenize gerek yoktur.