Bu kod yayın modunda takılıyor, ancak hata ayıklama modunda sorunsuz çalışıyor

Bununla karşılaştım ve hata ayıklama ve bırakma modunda bu davranışın nedenini bilmek istiyorum.

public static void Main(string[] args)
{            
   bool isComplete = false;

   var t = new Thread(() =>
   {
       int i = 0;

        while (!isComplete) i += 0;
   });

   t.Start();

   Thread.Sleep(500);
   isComplete = true;
   t.Join();
   Console.WriteLine("complete!");
}

Sanırım optimizer, isCompletedeğişkendeki 'uçucu' anahtar kelimenin olmaması nedeniyle kandırılıyor .

Elbette ekleyemezsiniz çünkü bu yerel bir değişken. Ve tabii ki, yerel bir değişken olduğu için buna hiç ihtiyaç duyulmamalıdır, çünkü yerliler yığın halinde tutulur ve doğal olarak her zaman "taze" dir.

Ancak , derledikten sonra artık yerel bir değişken değildir . Anonim bir temsilciden erişildiğinden, kod bölünür ve aşağıdaki gibi bir yardımcı sınıfa ve üye alanına çevrilir:

public static void Main(string[] args)
{
    TheHelper hlp = new TheHelper();

    var t = new Thread(hlp.Body);

    t.Start();

    Thread.Sleep(500);
    hlp.isComplete = true;
    t.Join();
    Console.WriteLine("complete!");
}

private class TheHelper
{
    public bool isComplete = false;

    public void Body()
    {
        int i = 0;

        while (!isComplete) i += 0;
    }
}

Artık çok iş parçacıklı bir ortamdaki JIT derleyicisinin / optimize edicisinin, TheHelpersınıfı işlerken , aslında yöntemin başlangıcında bir yazmaç veya yığın çerçevesindeki değeri önbelleğe alabileceğini ve yöntem bitene kadar asla yenilemeyeceğini hayal edebiliyorum . Bunun nedeni, iş parçacığı ve yöntemin "= true" çalıştırılmadan SONA ERMEYECEĞİNİN HİÇBİR GARANTİSİ olmamasıdır, bu yüzden garanti yoksa, neden önbelleğe almayasınız ve yığın nesnesini her seferinde okumak yerine bir kez okuyarak performans artışı elde etmeyiniz. yineleme.falseBody()

Anahtar kelimenin volatilevar olmasının nedeni budur .

Bu yardımcı sınıf olabilmesi için doğru bir minik daha iyi bit ¹⁾ çok kanallı ortamlarda, bu olmalıdır:

    public volatile bool isComplete = false;

ancak elbette, otomatik olarak oluşturulmuş kod olduğu için ekleyemezsiniz. Daha iyi bir yaklaşım, lock()okuma ve yazma işlemlerinin etrafına bazı metinler eklemek isCompletedveya bunu çıplak metal yapmaya çalışmak yerine kullanıma hazır diğer bazı senkronizasyon veya iş parçacığı / görevlendirme yardımcı programlarını kullanmak olacaktır (çıplak metal olmayacaktır , CLR'de GC, JIT ve (..) ile C # olduğundan).

Hata ayıklama modundaki fark büyük olasılıkla hata ayıklama modunda birçok optimizasyonun hariç tutulması nedeniyle oluşur, böylece ekranda gördüğünüz kodda hata ayıklayabilirsiniz. Bu nedenle while (!isComplete), orada bir kesme noktası ayarlayabileceğiniz için optimize edilmemiştir ve bu nedenle isComplete, yöntemin başlangıcında bir yazmaçta veya yığında agresif bir şekilde önbelleğe alınmaz ve her döngü yinelemesinde öbek üzerindeki nesneden okunur.

BTW. Bu sadece benim tahminlerim. Derlemeye bile çalışmadım.

BTW. Bir hata gibi görünmüyor; daha çok belirsiz bir yan etkiye benziyor. Ayrıca, bu konuda haklıysam, bu bir dil eksikliği olabilir - C #, yakalanan ve kapanışlarda üye alanlara yükseltilen yerel değişkenlere 'geçici' anahtar kelime yerleştirmeye izin vermelidir.

¹⁾ yaklaşık Eric Lippert bir yorumlar için aşağıya bakın volatileve / veya güvenerek bu kodu sağlamada karmaşayı seviyelerini gösteren bu çok ilginç makale volatileolan güvenli ..uh, iyi ..uh, en Tamam diyelim.

Quetzalcoatl'ın cevap doğrudur. Daha fazla ışık tutmak için:

C # derleyicisinin ve CLR jitterinin, mevcut iş parçacığının çalışan tek iş parçacığı olduğunu varsayan pek çok optimizasyon yapmasına izin verilir. Bu optimizasyonlar, mevcut iş parçacığının çalışan tek iş parçacığı olmadığı bir dünyada programı yanlış yapıyorsa, bu sizin sorununuzdur . Sen edilir gerekli yapıyorsun parçacıklı deli ne şeyler derleyici ve stres anlatmak çok iş parçacıklı programlar yazmak için.

Bu özel durumda, değişkenin döngü gövdesi tarafından değişmediğini gözlemlemesi ve dolayısıyla - varsayım gereği bu çalışan tek iş parçacığı olduğu için - değişkenin asla değişmeyeceği sonucuna varması için seğirmeye izin verilir - ancak gerekli değildir. Hiç değişmezse, değişkenin doğruluk açısından döngü boyunca her seferinde değil, bir kez kontrol edilmesi gerekir . Ve aslında olan budur.

Bunu nasıl çözebilirim? Çok iş parçacıklı programlar yazmayın . Çoklu iş parçacığını doğru kullanmak, uzmanlar için bile inanılmaz derecede zordur. Gerekirse , hedefinize ulaşmak için en üst düzey mekanizmaları kullanın . Buradaki çözüm, değişkeni uçucu hale getirmek değildir. Buradaki çözüm, iptal edilebilir bir görev yazmak ve Görev Paralel Kitaplığı iptal mekanizmasını kullanmaktır . TPL'nin iş parçacığı mantığını doğru bir şekilde alma konusunda endişelenmesine izin verin ve iptal işlemi iş parçacıkları arasında düzgün bir şekilde gönderin.

Çalışan sürece ekledim ve buldum (hata yapmadıysam, bu konuda çok pratik yapmadım) Threadyöntemin şuna çevrildiğini:

debug051:02DE04EB loc_2DE04EB:                            
debug051:02DE04EB test    eax, eax
debug051:02DE04ED jz      short loc_2DE04EB
debug051:02DE04EF pop     ebp
debug051:02DE04F0 retn

eax(değerini içeren isComplete) ilk kez yüklenir ve asla yenilenmez.

Gerçekten bir cevap değil, ancak konuya biraz daha ışık tutmak için:

Sorun ne zaman gibi görünüyor ilamda vücudun içinde ilan edilir ve o oluyor sadece atama ifadesinde okuyun. Aksi takdirde kod, yayın modunda iyi çalışır:

1. i lambda gövdesinin dışında beyan edildi:

   int i = 0; // Declared outside the lambda body
   
   var t = new Thread(() =>
   {
       while (!isComplete) { i += 0; }
   }); // Completes in release mode

2. i atama ifadesinde okunmaz:

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { i = 0; }
   }); // Completes in release mode

3. i ayrıca başka bir yerde okunur:

   var t = new Thread(() =>
   {
       int i = 0;
       while (!isComplete) { Console.WriteLine(i); i += 0; }
   }); // Completes in release mode

Bahse girerim bazı derleyici veya JIT optimizasyonu i, işleri karıştırmaktır. Benden daha zeki biri muhtemelen konuya daha fazla ışık tutacaktır.

Yine de, bu konuda çok fazla endişelenmem çünkü benzer kodun gerçekte herhangi bir amaca hizmet edeceği yeri göremiyorum.