Windows API'deki reader/writer lock'ta ortaya çıkan hata

Windows'ta std::shared_mutex için olası hata

• Bir yazılım ekibi, Windows'ta std::shared_mutex ile ilgili beklenmedik bir davranış keşfetti.
• Bu sorun yalnızca MSVC'de ortaya çıkıyor; MinGW'de veya diğer platformlarda görülmüyor.
• Ana thread özel kilidi aldıktan sonra birden fazla alt thread paylaşımlı kilit almaya çalıştığında, yaklaşık her 1000 denemede 1 kez bir "deadlock" oluşuyor.
• Deadlock oluştuğunda yalnızca tam olarak 1 alt thread paylaşımlı kilidi başarıyla alabiliyor; kalan alt thread'ler lock_shared() içinde sonsuza kadar bloklanıyor.
• Bu sorun, std::shared_mutex, std::shared_lock/std::unique_lock ya da SRW fonksiyonları doğrudan çağrıldığında gözlemleniyor.

Kod örneği ve hatanın yeniden üretilmesi

• Sorunu yeniden üretebilen basit bir kod örneği sunuluyor.
• Kod, ana thread'in özel kilidi alıp birden fazla alt thread'in paylaşımlı kilidi alıp sonra bırakması sürecini tekrar ediyor.
• Bu kod, yalnızca Windows MSVC implementasyonunda std::shared_mutex ile ilişkili hatayı gösteriyor.

Uzman görüşleri

• STL geliştiricisi, bunun bir Windows API hatası gibi göründüğünü belirtiyor.
• Hatanın nasıl raporlanması gerektiğine dair bir tartışma yürütüldü ve STL geliştiricisi hatayı dahili olarak raporladı.
• Diğer kullanıcılar da sorunu ayrıntılı biçimde inceledi ve SRWLock implementasyonundaki belirli bir hatanın daraltılmasına katkı sağladı.

GN⁺ görüşü

• Bu yazı, özellikle C++ geliştiricileri için önemli bilgiler sunuyor. Çünkü std::shared_mutex içindeki potansiyel bir hata, çok iş parçacıklı uygulamalardaki senkronizasyon mekanizmalarını etkileyebilir.
• Hata doğrulanırsa, bu durum C++ standart kütüphanesi implementasyonuna duyulan güveni etkileyebilir. Geliştiricilerin bu tür sorunların farkında olması ve alternatif senkronizasyon mekanizmalarını değerlendirmesi gerekebilir.
• Bu sorun özellikle yüksek performanslı veya gerçek zamanlı sistemlerde önemli olabilir. Çünkü böyle sistemlerde deadlock kritik sonuçlara yol açabilir.
• Geliştiriciler, bu teknolojiyi benimsemeden önce ilgili platform ve derleyici üzerinde kapsamlı testler yaparak bu tür hataların bulunmadığını doğrulamalıdır.
• Bu sorunları azaltmak için geliştiriciler, Boost kütüphanesi gibi alternatif senkronizasyon kütüphanelerini değerlendirebilir. Boost geniş çapta test edilmiş ve birçok platformda kullanılmış olduğundan, bu tür sorunlara karşı güvenilir bir alternatif sunabilir.

[GN⁺]

Hacker News yorumları

• Bir kullanıcı, böylesine temel bir sorunun neden bu kadar uzun süre fark edilmediğini merak ettiğini ve başka bir kullanıcının sunduğu ikna edici yanıtı anıyor. Paylaşımlı modda kilit almaya çalışan bir iş parçacığının yanlışlıkla özel modda kilit alabilmesinin mümkün olduğuna dikkat çekiyor. Bunun, paylaşımlı modda alma yapan iş parçacığı ile özel modda bırakma yapan iş parçacığı aynı anda çalıştığında atomik bit test et ve ayarla işlemlerinin çakışmasından kaynaklandığını belirtiyor.

  • Bir kullanıcı, paylaşımlı kilit alınırken diğer tüm iş parçacıklarının paylaşımlı kilit almayı beklediği bir yeniden üretim kodu bulunduğunu açıklıyor; bu da herhangi bir çalışan iş parçacığı yanlışlıkla özel kilidi alırsa kilitlenmeye yol açabiliyor. Tipik kullanım durumlarında iş parçacıkları birbirini beklemediği için kilitlenme oluşmuyor.

• Başka bir kullanıcı, Reader/Writer kilitlerinde ortaya çıkan ince hatalara şaşırmadığını belirtiyor ve C++11 ile std::shared_mutex öncesinde Win32 tabanlı iç uygulamalar üzerinde çalıştığı deneyimini paylaşıyor. Paylaşımlı kilitlerle ilgili kötü deneyimleri nedeniyle, kesinlikle gerekli olmadıkça bunlardan kaçınmaya çalıştığını söylüyor.

  • Bir kullanıcı, paylaşımlı kilitlerle ilgili olumsuz deneyimini paylaşarak std::shared_mutex performansının std::mutexe kıyasla belirgin biçimde daha kötü olduğunu, bu yüzden veriyi çift arabelleklemeyle yönetmenin daha hızlı olduğunu belirtiyor.

• Bir kullanıcı, başlığın yanıltıcı olduğunu belirtiyor ve gerçek hatanın Windows API içindeki slim reader/writer (SRW) kilidinde olduğunu, bunun da std::shared_mutex SRW kilidini kullanarak uygulandığı için keşfedildiğini açıklıyor. Bir Microsoft çalışanı, hatanın Windows API ekibine dahili olarak iletildiğini doğruluyor.

  • Bir kullanıcı, yanıltıcı başlığa dikkat çekerek asıl sorunun Windows API'nin SRW kilidinde olduğunu ve bir Microsoft çalışanının hatanın bildirildiğini doğruladığını belirtiyor.

• Bir kullanıcı, aynı sorunun WINE uygulamasında da ortaya çıkıp çıkmadığını merak ediyor ve kendi özel XP kurulumunda da test etmek istediğini söylüyor. Bu kurulumda SRW API dahil çeşitli uzantılar eklediğini ve SRW uygulamasına dayanan keyed event API'de kilitlenmeye neden olan yarış durumunu düzeltmek için çekirdeği yamaladığını belirtiyor.

  • Bir kullanıcı, aynı sorunun WINE uygulamasında da olup olmadığını merak ettiğini ve bunu kendi özel XP kurulumunda test etmek istediğini söylüyor. Bu kurulumda SRW API dahil çeşitli uzantılar eklediğini ve SRW uygulamasına dayanan keyed event API'de kilitlenmeye yol açan yarış durumunu düzeltmek için çekirdeği yamaladığını belirtiyor.

• Programda bir hata olduğu belirtiliyor. Atomik olmayan değişkenlerle atomik değişkenler karıştırılarak yield() kontrol döngüsünde kullanılıyor ve atomik olmayan değişkenler diğer iş parçacıklarına karşı önbellek tutarlılığı garanti etmiyor. Bu nedenle döngü sonsuza kadar çalışabiliyor.

  • Bir kullanıcı, programdaki hataya dikkat çekerek atomik olmayan değişkenlerle atomik değişkenlerin birlikte kullanılmasından doğan sorunu açıklıyor. Atomik olmayan değişkenlerin önbellek tutarlılığı sağlamaması nedeniyle döngünün sonsuza kadar sürebileceğini belirtiyor.

• Bir kullanıcı, bu hatanın 2008'deki Vista sürümüne kadar uzandığını ve bu kadar uzun süre kimsenin fark etmemiş olmasına şaşırdığını söylüyor. Tipik rwlock kullanımında paylaşımlı kilidin alınamadığı rastgele durumlar görülebileceğini ancak kilitlenme yaşanmadığını belirtiyor.

  • Bir kullanıcı, bu hatanın Vista sürümüne kadar uzandığını ve uzun yıllar boyunca fark edilmemiş olmasına şaşırdığını ifade ediyor. Tipik rwlock kullanımında kilitlenme olmasa da paylaşımlı kilidin alınamadığı durumlar oluşabileceğini belirtiyor.

• Bir kullanıcı, Windows API için hata bildirmenin çok zor olduğunu belirtiyor ve Feedback Hub üzerinden bildirim yapmasının söylendiğini, ancak bunun neredeyse hiç işe yaramadığını eleştiriyor. Söz konusu kullanıcı, özel sahiplik sahibi bıraktıktan sonra birden fazla okuma iş parçacığının aynı anda paylaşımlı sahiplik almaya çalıştığı durumda SRWLOCK'un kilitlenebileceği hatasını bildirdiğini söylüyor.

  • Bir kullanıcı, Windows API için hata bildirmenin çok zor olduğunu ve Feedback Hub üzerinden bildirimin etkili olmadığını eleştiriyor. SRWLOCK ile ilgili bir hata bildirdiğini paylaşıyor.

• Bir kullanıcı, geçmişte MS ürünleri satın alındığında destek vakası alınabildiğini ve gerçekten bir hata bulunursa bu destek vakasının iade edildiğini hatırlıyor. Bunun geliştiriciler için faydalı olduğunu ve MS için de gerçek sorunları bulup belgeleri iyileştirmeye yardımcı olan iyi bir geri bildirim sistemi sunduğunu belirtiyor. Bu programın hâlâ var olup olmadığını merak ediyor.

  • Bir kullanıcı, geçmişte MS ürünleriyle gelen destek vakalarını hatırlıyor ve bu sistemin hem geliştiriciler hem de MS için yararlı olduğunu belirtiyor. Bu programın bugün hâlâ mevcut olup olmadığını merak ediyor.

• Son olarak bir kullanıcı, Windows API için hata bildirmenin zor olmasına dair hayal kırıklığını dile getiriyor.

  • Bir kullanıcı, Windows API için hata bildirmenin zorluğu karşısındaki hayal kırıklığını ifade ediyor.