Yazılım hatalarından ders almak – Bölüm 3: Bir Mars sondası kontrolden çıkıyor

Modern yazılım geliştirmede rekabet her yerde mevcuttur. Küçük uygulamalar bile genellikle çok çekirdekli sistemlerde çalışır, veritabanlarıyla etkileşimde bulunur, ağ yanıtlarını bekler veya dosyalar ve bellek alanları gibi kaynakları paylaşır. Dağıtılmış sistemlerde ve gömülü yazılımlarda, farklı süreçlerin genellikle gerçek zamanlı koşullarda birbirine tepki vermesi gerekir. Uygulama, aynı anda birden fazla şeyin meydana gelebildiği anda, seri programlarda asla ortaya çıkmayacak yeni hata sınıflarının ortaya çıktığını göstermektedir.

Model 3: Eşzamanlılık ve planlama: süreçler birbirini engellediğinde

Ünlü bir örnek, 1997 NASA misyonu olan Mars Pathfinder'dır. İnişin kendisi muhteşem bir başarıydı: sonda yavaşça Mars'a dokundu ve verileri geri göndermeye başladı. Ancak kısa süre sonra ara sıra sistem çökmeleri ve otomatik sıfırlamalar meydana geldi ve bu da ekibin alarma geçmesine neden oldu.

Bunun nedeni, klasik bir rekabet sorunu olan önceliklerin tersine dönmesiydi. Gerçek zamanlı bir işletim sisteminde farklı önceliklere sahip görevler vardır. Yüksek öncelik şu anlama gelir: Bu görev hazır olduğunda mümkün olan en kısa sürede çalıştırılmalıdır. Arka plan bunu engellememelidir.

Böyle yüksek öncelikli görevlerden biri, hava durumu sensöründen gelen verileri işleyen Pathfinder'da yürütülüyordu. Ancak, paylaşılan bir kaynağa, bu durumda düşük öncelikli bir görev tarafından yönetilen bir mutekse erişime ihtiyacı vardı. Bu düşük öncelikli görevin yerini sürekli olarak orta öncelikli bir görev aldı. Sonuç: Yüksek öncelikli görev, dolaylı olarak hiç yapılmamış düşük öncelikli bir görevi bekliyordu.

Bu “önceliğin tersine çevrilmesi” olgusu, sistemin belirli yük durumlarında donmasına ve sonunda yeniden başlatılmasına neden oldu. Prensipte çözüm basitti: Geliştiriciler, VxWorks gerçek zamanlı işletim sisteminde öncelik mirasını etkinleştirdiler. Sonuç olarak, düşük öncelikli engelleme görevi, daha yüksek değerli bir görev onu bekler beklemez geçici olarak yüksek önceliği devraldı. Düğüm çözüldü ve çarpmalar ortadan kalktı.

Bu örnek öğreticidir çünkü birkaç tipik modeli göstermektedir:

• Eşzamanlılık hatalarının yeniden üretilmesi zordur: genellikle yalnızca belirli yük profillerinde ortaya çıkarlar.
• Fazlalık veya tekrarlama otomatik olarak işe yaramaz: eğer hata tasarımdaysa, tüm örnekleri eşit şekilde etkiler.
• Planlamadaki en küçük ayrıntılar fark yaratabilir: Yazılım bin kez doğru çalışabilir ve bin ilk seferde başarısız olabilir.

Modern uygulamalarda benzer sorunlar kilitlenmeler, yarış koşulları veya canlı kilitlenmeler şeklinde ortaya çıkabilir. Bunlar genellikle yerel test yürütme sırasında ortaya çıkmaz, yalnızca üretimde gerçek yük ve gerçek paralellik devreye girdiğinde ortaya çıkar. Fakat bu tür hatalardan nasıl kaçınılabilir?

1. Blok hiyerarşilerini temizle: Birden fazla kaynağı kilitlediğinizde, bunları her zaman aynı sırayla kilitlemeniz gerekir.
2. Öncelikli protokolleri kullanın: Priority Inheritance veya Priority Roof gibi mekanizmalar birçok gerçek zamanlı işletim sisteminde ve hatta modern çerçevelerde mevcuttur.
3. Ayrılmış rekabet: Paylaşılan durumları doğrudan engellemek yerine, mesaj aktarma veya aktör modellerine sahip mimariler yarış koşullarını önleyebilir.
4. Deterministik testler ve simülasyonlar: Özel test çerçeveleri, nadir görülen çakışmaları tekrarlanabilir hale getirmek için süreçleri özellikle geciktirebilir veya zamanlayıcıları manipüle edebilir.
5. Telemetri ve izleme: Kilitlemelerin alışılmadık derecede uzun bir süre devam etmesi halinde, çalışma sırasında da görülebilmelidir.

Bu arada, web arka uçları veya bulut hizmetleri geliştiren ekipler de aynı tehlikeyle karşı karşıyadır, ancak biraz farklı bir biçimde: veritabanı işlemleri, dağıtılmış önbellekler veya eşzamanlı API istekleri benzer etkilere sahip olabilir. Yavaş bir arka plan işlemi kilidi engellerken, paralel isteklerin seli bu durumu daha da kötüleştirir.

Bu nedenle Pathfinder olayından alınan ders kalıcıdır: Eşzamanlılık, ücretsiz bir performans artışı değil, geliştiricilerin açıkça tasarlaması ve izlemesi gereken karmaşık bir sistemdir. Eşzamanlılığı küçük bir sorun olarak ele alan herkes, er ya da geç yeniden üretilmesi zor ve felaketle sonuçlanabilecek hatalarla karşılaşacaktır.

Yazılım hatalarından ders almak: Seri

Bu makale serisi, endüstri veya teknolojiden bağımsız olarak pratikte tekrar tekrar ortaya çıkan dokuz tipik hata sınıfını sunmaktadır. Her kategoride seride somut bir örnek sunulacak, nedenler analiz edilecek ve yazılım geliştiricilerin uzun vadede neler öğrenebilecekleri bundan çıkarılacak.

Bir sonraki bölümde şunları okuyacaksınız: Zaman, takvim ve coğrafya: Saat ne düşündüğünüzü ölçmediğinde.

(DSÖ)