list :: empty () çok iş parçacıklı davranış?

Öğeleri kapmak için farklı konuların olmasını istediğim bir liste var. Muteksin liste boşken kilitlenmesini önlemek için kilitlemeden empty()önce kontrol ederim .

Çağrı list::empty()% 100 doğru değilse sorun değil. Sadece eşzamanlı list::push()ve list::pop()aramaların çökmesini veya bozulmasını önlemek istiyorum .

VC ++ ve Gnu GCC'nin sadece bazen empty()yanlış olacağını ve daha kötü bir şey olacağını varsayabilir miyim ?

if(list.empty() == false){ // unprotected by mutex, okay if incorrect sometimes
    mutex.lock();
    if(list.empty() == false){ // check again while locked to be certain
         element = list.back();
         list.pop_back();
    }
    mutex.unlock();
}

Çağrı list::empty()% 100 doğru değilse sorun değil.

Hayır, sorun değil. Listenin bazı senkronizasyon mekanizmalarının (boşluğu kilitleme) dışında boş olup olmadığını kontrol ederseniz veri yarışınız olur. Bir veri yarışına sahip olmak, tanımlanmamış davranışınız olduğu anlamına gelir. Tanımlanmamış davranışa sahip olmak, artık program hakkında bir neden bulamayacağımız anlamına gelir ve aldığınız çıktılar "doğru" olur.

Akıl sağlığınıza değer verirseniz, kontrol etmeden önce performans isabetini alır ve muteksi kilitlersiniz. Bununla birlikte, liste sizin için doğru kap bile olmayabilir. Onunla ne yaptığınızı tam olarak bize bildirirseniz, daha iyi bir kap önerebiliriz.

Birbirleri ile eşitlenmemiş bir okuma ve yazma (büyük olasılıkla sizeüyesine, std::listböyle adlandırıldığını varsayarsak) vardır . Bir iş parçacığının iç tarafa girip yürütürken bir iş parçacığının (dışınızda ) aradığını düşünün . Daha sonra, muhtemelen değiştirilen bir değişkeni okuyorsunuz. Bu tanımsız bir davranıştır.empty()if()if()pop_back()

İşlerin nasıl yanlış gidebileceğine bir örnek olarak:

Yeterince akıllı bir derleyici mutex.lock(), list.empty()dönüş değerini muhtemelen değiştiremediğini ve böylece iç ifkontrolü tamamen atlayamayacağını görebiliyordu , sonunda pop_backbirinciden sonra son öğesi kaldırılmış bir listeye yol açtı if.

Bunu neden yapabilir? Eşzamanlama yoktur list.empty(), bu nedenle eşzamanlı olarak değiştirilirse, bu bir veri yarışı oluşturur. Standart, programların veri yarışlarına sahip olmayacağını, bu nedenle derleyicinin bunu kabul edeceğini söylüyor (aksi takdirde neredeyse hiçbir optimizasyon yapamaz). Bu nedenle, senkronize edilmemiş olan tek iş parçacıklı bir perspektif varsayabilir list.empty()ve sabit kalması gerektiği sonucuna varabilir.

Bu, kodunuzu kırabilecek çeşitli optimizasyonlardan (veya donanım davranışlarından) yalnızca biridir.