Çoklu iş parçacığı programı en iyi duruma getirilmiş durumda kalmış ancak normalde -O0'da çalışıyor

Basit bir çok iş parçacığı içeren programlar yazdım:

static bool finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Bu hata ayıklama modunda normal davranır Görsel stüdyoda veya -O0içinde gc c ve sonra sonucu çıktısını 1saniye. Ancak yapışmış ve Release modunda veya hiçbir şey yazdırmıyor -O1 -O2 -O3.

Olmayan bir atom olmayan korunan değişkeni erişen iki konu vardır UB Bu endişeler finished. Bunu düzeltmek için finishedtür yapabilirsiniz std::atomic<bool>.

Düzeltmem:

#include <iostream>
#include <future>
#include <atomic>

static std::atomic<bool> finished = false;

int func()
{
    size_t i = 0;
    while (!finished)
        ++i;
    return i;
}

int main()
{
    auto result=std::async(std::launch::async, func);
    std::this_thread::sleep_for(std::chrono::seconds(1));
    finished=true;
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Çıktı:

result =1023045342
main thread id=140147660588864

Coliru'da Canlı Demo

Birisi 'Bu bir bool- muhtemelen bir bit. Bu nasıl atomik olmayabilir? ' (Kendime çoklu iplik geçirmeye başladığımda yaptım.)

Ancak, gözyaşı eksikliğinin std::atomicsize veren tek şey olmadığını unutmayın. Ayrıca, derleyicinin değişkeni yeniden okumanın her zaman aynı değeri göreceğini varsaymasını engelleyerek, birden çok iş parçacığından eşzamanlı okuma + yazma erişimi sağlar.

boolKorunmasız, atomik olmayan yapmak ek sorunlara neden olabilir:

• Derleyici, değişkeni bir sicile ve hatta CSE çoklu erişimini bir sınıfa optimize etmeye ve bir döngüden bir yükü kaldırmaya karar verebilir.
• Değişken bir CPU çekirdeği için önbelleğe alınabilir. (Gerçek hayatta, CPU'lar tutarlı önbellekleri sahiptir . Bu gerçek bir sorun değildir, ancak C ++ standart ++ uyumlu olmayan ortak bellek uygulamalarını varsayımsal C kapağı için gevşek yeterli atomic<bool>olan memory_order_relaxedmağaza / yük çalışması, ancak burada volatileolmaz. Kullanılması gerçek C ++ uygulamaları üzerinde pratikte çalışmasına rağmen, bunun için uçucu olan UB olurdu.)

Bunun olmasını önlemek için derleyiciye açıkça yapmamaları söylenmelidir.

volatileBu konunun potansiyel ilişkisi ile ilgili gelişen tartışma hakkında biraz şaşırdım . Böylece, iki sentimi harcamak istiyorum:

• Uçucu iplikler için faydalı mı
• Kim kötü bir optimizasyon derleyicisinden korkuyor? .

Scheff'ın cevabı kodunuzu nasıl düzelteceğinizi açıklar. Bu durumda gerçekte neler olduğuna dair biraz bilgi ekleyeceğimi düşündüm.

Optimizasyon seviyesi 1 ( ) kullanarak kodunuzu godbolt'ta derledim-O1 . İşleviniz şöyle derlenir:

func():
  cmp BYTE PTR finished[rip], 0
  jne .L4
.L5:
  jmp .L5
.L4:
  mov eax, 0
  ret

Peki, burada neler oluyor? İlk olarak, bir karşılaştırmamız var: cmp BYTE PTR finished[rip], 0- Bu finished, yanlış olup olmadığını kontrol eder .

Eğer öyleyse değil yanlış (aka true) biz ilk çalıştırmada döngü çıkmak gerekir. Bu gerçekleştirilir göre jne .L4olan j umps N ot e etikete Qual .L4değeri burada i( 0) daha sonra kullanmak ve ve fonksiyon için bir kayıt saklanır.

O takdirde ise ancak yanlış, biz taşımak

.L5:
  jmp .L5

Bu, .L5atlama komutunun kendisi olan etiketlemek için koşulsuz bir atlamadır .

Başka bir deyişle, iş parçacığı sonsuz meşgul döngüsüne konur.

Peki bu neden oldu?

İyileştirici ile ilgili olarak, dişler tasarımının dışındadır. Diğer iş parçacıklarının eşzamanlı olarak değişkenleri okumadığını veya yazmadığını varsayar (çünkü bu, veri yarışı UB olacaktır). Erişimleri optimize edemeyeceğini söylemelisiniz. Scheff'in cevabı burada devreye giriyor. Onu tekrarlamak için uğraşmayacağım.

Optimize ediciye, finisheddeğişkenin işlevin yürütülmesi sırasında potansiyel olarak değişebileceği söylenmediğinden finished, işlevin kendisi tarafından değiştirilmediğini görür ve sabit olduğunu varsayar.

Optimize edilmiş kod, işleve sabit bir bool değeriyle girilmesinden kaynaklanacak iki kod yolunu sağlar; ya döngüyü sonsuz olarak çalıştırır ya da döngü asla çalıştırılmaz.

en -O0(beklendiği gibi) derleyici uzaklıkta halka gövdesi ve karşılaştırma optimize etmez:

func():
  push rbp
  mov rbp, rsp
  mov QWORD PTR [rbp-8], 0
.L148:
  movzx eax, BYTE PTR finished[rip]
  test al, al
  jne .L147
  add QWORD PTR [rbp-8], 1
  jmp .L148
.L147:
  mov rax, QWORD PTR [rbp-8]
  pop rbp
  ret

bu nedenle fonksiyon, optimize edilmediğinde, burada atomisite eksikliği tipik olarak bir problem değildir, çünkü kod ve veri tipi basittir. Muhtemelen burada karşılaşabileceğimiz en kötü, bir olması gereken işey tarafından kapalı bir değerdir .

Veri yapılarına sahip daha karmaşık bir sistemin bozuk veri veya yanlış yürütme ile sonuçlanma olasılığı daha yüksektir.

Öğrenme eğrisindeki bütünlük uğruna; global değişkenleri kullanmaktan kaçınmalısınız. Statik yaparak iyi bir iş çıkardınız, bu yüzden çeviri birimi için yerel olacak.

İşte bir örnek:

class ST {
public:
    int func()
    {
        size_t i = 0;
        while (!finished)
            ++i;
        return i;
    }
    void setFinished(bool val)
    {
        finished = val;
    }
private:
    std::atomic<bool> finished = false;
};

int main()
{
    ST st;
    auto result=std::async(std::launch::async, &ST::func, std::ref(st));
    std::this_thread::sleep_for(std::chrono::seconds(1));
    st.setFinished(true);
    std::cout<<"result ="<<result.get();
    std::cout<<"\nmain thread id="<<std::this_thread::get_id()<<std::endl;
}

Wandbox'ta canlı