Öyleyse, çocuklar, şimdi özyinelemeli sessiz erişimin kullanım durumunu tartışalım, yani
hangi durumda, yeni vergilerle ilgili ne kullanacaksınız ve hangi durumda normal muteks çalışmaz?
Bu yüzden büyük yazılım projelerinde geliştiriciler fonksiyonları bağımsız olarak yazarlar.
Her işlev bir görevle ilişkilendirilir.
Tamam.
Diyelim ki bir geliştirici bu fonksiyonu yazdı.
Bu fonksiyonun amacı, belirli bir öğrenci kaydını bu öğrenci veritabanından silmektir.
Ve bunun çoklu çok iş parçacıklı bir yazılım olduğunu ve bu öğrenci veritabanının iş parçacıkları arasında veri yapılarını
güvence altına aldığını varsayalım.
Yani ideal olarak, geliştirici bir öğrenci veritabanı üzerinde herhangi bir okuma veya yazma işlemi gerçekleştirmeden önce öğrenci
veritabanı muteksini kilitleyecek ve ardından bir onur öğrencisi veritabanı üzerinde gerçekleştirmek istediği
işlemleri gerçekleştirecektir.
Bu durumda, geliştirici bu öğrenci veritabanından öğrenci kaydını silmektedir ve geliştiricinin
işi bittiğinde, Amtrak'ınkini açacağı açıktır.
Bu yüzden bu API ile ilgili herhangi bir sorun görmüyorum.
Mükemmel.
Şimdi, üç veya dört ay sonra ekibe yeni bir geliştiricinin katıldığını ve sisteme yeni bir
API eklediğini varsayalım.
Bu API öğrenciyi kaldırıyor ve bu API'nin amacı yürümektir, bu bir veritabanını çalıştırmak, toplamı
bu toplam sınırından daha az olan tüm öğrencileri bulmak ve öğrenci veritabanındaki toplamı bu
toplam sınırından daha az olan tüm öğrencileri silmektir.
Tamam.
Açıkçası, geliştirici yine öğrenci veritabanı muteksini kilitleyecektir.
Daha sonra öğrenci veritabanına erişecek, yani öğrenci veritabanındaki her bir kaydın üzerinde
yürüyecek, öğrenci veritabanındaki bir öğrenci olan kimliklerin toplam yüzdesini karşılaştıracak
ve toplam yüzde argüman olarak verilen değerden daha düşükse, öğrenci veritabanından bir kaydı silmek için
bu API'yi yeniden kullanacaktır.
Tamam.
Ve geliştiricinin işi bittiğinde, öğrenci veritabanı muteksinin kilidini açacağı açıktır.
Hayır, yazan geliştirici değil, Bu API'yi bir olarak adlandıralım.
Ve bu API'yi API aracı olarak adlandıralım.
Dolayısıyla API one'ı yazan geliştirici, API'nin dahili uygulamasının ne olduğunu görmekle de uğraşmayacaktır.
Basitçe iki numaralı API'yi çağırmak istiyor çünkü iki numaralı API'nin öğrenci kaydını bu öğrenci
veritabanından sileceğini biliyor.
Tamam.
Böylece iki numaralı API, birinci API'yi yazan geliştiricinin kara kutu aracı gibi çalışacaktır.
Tamam.
Ve şirkette olan da budur.
Bir kod yazdığınızda, önceden yazılmış API'leri çağırırsınız ve çoğu zaman sadece bu API'lere girdinin
ne olduğunu ve bu API'nin iç uygulamasının ne olduğunu merak etmeden bu API'nin çıktısının ne olduğunu
bilirsiniz.
Tamam.
Şimdi bu yaklaşımla, bir sorun olduğunu görebilirsiniz, sorun basitçe
şu ki, T izi bu API'yi yürüdüğünde, muteks burada kilitlenir ve trajedi olanı bu API'yi yürüdüğünde, denenen
yine aynı sessizliği burada kilitler.
Yani aynı muteks tekrar günlüğe kaydediliyor.
Bu, bu talimatta bir çıkmaza girileceği anlamına gelir.
Tamam.
Nedeni de basit.
Aynı yeni vergi, aynı tehditle tekrar kayıt altına alınıyor.
Şimdi, bu API için basit çözümün, öğrenci kaydının tamamen yeni bir API olduğuna
inanmanız olduğu iddia edilebilir.
Ve bu API'nin amacı basitçe öğrenci kaydını öğrenci veritabanından silmektir.
Elbette, ancak API'nin bu yeni sürümünde, yeni saldırılarda herhangi bir öğrenci veritabanı kilidini kaydetmeyecektik.
Şimdi bu API'nin uygulamasını görelim, böylece bunun öğrenci kaydını silmek için iki API olmadığını ve bu API'de herhangi
bir öğrenci veritabanı muteksini kilitlemeden öğrenci veritabanından bir öğrenci kaydını
silme zahmetine girdiğini görebilirsiniz.
Ve unutmayın, bu API'nin tanıtılmasının tek bir nedeni vardı, o da bu API'nin yeni vergiyi
zaten kilitleyen API'lerden çağrılabilmesiydi.
Tamam.
Yani bu geçerli bir çözümdür, bu çözümle ilgili tek sorun, her işlev için yinelenen bir
işlev yazmanız gerekmesidir.
Bu iki fonksiyon arasındaki tek fark, fonksiyonun bir versiyonunun sessiz ekseni kilitlemesi,
diğer versiyonunun ise aynı işlemi kilitleme veya kilit açma ve erişimi sınırlama olmadan yapmasıdır.
Bu da kod tekrarına yol açar.
Bu geçerli bir çözümdür, ancak bu çözümle birlikte çok sayıda kod tekrarı sorunu ortaya çıkar.
Bu işlevin 500 satırlık bir kod işlevi olabileceğini ve burada gördüğünüz kadar basit değil, karmaşık bir işlev olabileceğini
her zaman gözünüzde canlandırabilirsiniz.
Şimdi aynı senaryoyu tekrar görselleştirelim.
Ancak bir dakika ekseni yerine, bu yeni vergilerin özyinelemeli yeni vergiler olduğunu varsayalım.
Dolayısıyla, eğer bu yeni vergiler elbette programda kullanılan yeni vergiler ise, o zaman
bu iki API mükemmeldir, kendi kendini tamamlar ve hiçbir hata yoktur.
Tamam.
İçerideki tehdit bu API'yi çağırdığında, muteks burada kaydedilir, buna bir numaralı yuva diyelim ve aynı sessiz
erişim burada aynı iş parçacığı tarafından kaydedilir.
Tamam.
Ve tabii ki, dediğim gibi, bu özyinelemeli kök erişiminin kilidi, aynı iş parçacığı, aynı özyinelemeli mutasyonlar
tarafından kaydedildiği ve burada kaydedildiği ve aynı özyinelemeli dizinler tarafından kaydedildiği ve burada da kaydedildiği
kadar açılmalıdır.
Ve gerileyici yeni bir vergi olduğu için, 381, CPA'dan bir program yürütmeye başladığında bu
talimatta kilitlenme durumuna girmeyecek, öğrenciyi kaldıracaktır.
Yeni kazılar, aynı API'nin muteksi zaten kilitleyen başka bir API'den çağrılma olasılığının olduğu
senaryolarda işleri basitleştirir, bu durumlarda özyinelemeli kök erişimi kullanmanız
gerekir.
Yani bu, yeni vergilerin tekrarlandığı bir durumdu.
Umarım bu örnekle, özyinelemeli Metaxa'ları neden ve nerede kullanmanız gerektiği ve normal mutex'in hangi
senaryolarda başarısız olacağı çok net bir şekilde anlaşılmıştır.