WEBVTT 00:00.930 --> 00:05.790 Öyleyse, çocuklar, şimdi özyinelemeli sessiz erişimin kullanım durumunu tartışalım, yani 00:05.790 --> 00:11.190 hangi durumda, yeni vergilerle ilgili ne kullanacaksınız ve hangi durumda normal muteks çalışmaz? 00:12.120 --> 00:16.560 Bu yüzden büyük yazılım projelerinde geliştiriciler fonksiyonları bağımsız olarak yazarlar. 00:17.130 --> 00:19.890 Her işlev bir görevle ilişkilendirilir. 00:20.460 --> 00:20.820 Tamam. 00:21.300 --> 00:24.510 Diyelim ki bir geliştirici bu fonksiyonu yazdı. 00:25.500 --> 00:30.630 Bu fonksiyonun amacı, belirli bir öğrenci kaydını bu öğrenci veritabanından silmektir. 00:31.380 --> 00:37.260 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ı 00:37.500 --> 00:39.810 güvence altına aldığını varsayalım. 00:40.440 --> 00:47.040 Yani ideal olarak, geliştirici bir öğrenci veritabanı üzerinde herhangi bir okuma veya yazma işlemi gerçekleştirmeden önce öğrenci 00:47.040 --> 00:52.470 veritabanı muteksini kilitleyecek ve ardından bir onur öğrencisi veritabanı üzerinde gerçekleştirmek istediği 00:52.470 --> 00:54.540 işlemleri gerçekleştirecektir. 00:54.990 --> 01:01.200 Bu durumda, geliştirici bu öğrenci veritabanından öğrenci kaydını silmektedir ve geliştiricinin 01:01.200 --> 01:04.900 işi bittiğinde, Amtrak'ınkini açacağı açıktır. 01:05.640 --> 01:08.060 Bu yüzden bu API ile ilgili herhangi bir sorun görmüyorum. 01:08.070 --> 01:09.390 Mükemmel. 01:10.560 --> 01:17.670 Şimdi, üç veya dört ay sonra ekibe yeni bir geliştiricinin katıldığını ve sisteme yeni bir 01:17.670 --> 01:20.160 API eklediğini varsayalım. 01:21.270 --> 01:28.110 Bu API öğrenciyi kaldırıyor ve bu API'nin amacı yürümektir, bu bir veritabanını çalıştırmak, toplamı 01:28.380 --> 01:35.070 bu toplam sınırından daha az olan tüm öğrencileri bulmak ve öğrenci veritabanındaki toplamı bu 01:35.070 --> 01:39.570 toplam sınırından daha az olan tüm öğrencileri silmektir. 01:40.440 --> 01:40.830 Tamam. 01:41.280 --> 01:45.800 Açıkçası, geliştirici yine öğrenci veritabanı muteksini kilitleyecektir. 01:46.350 --> 01:52.710 Daha sonra öğrenci veritabanına erişecek, yani öğrenci veritabanındaki her bir kaydın üzerinde 01:52.710 --> 01:58.890 yürüyecek, öğrenci veritabanındaki bir öğrenci olan kimliklerin toplam yüzdesini karşılaştıracak 01:58.890 --> 02:06.090 ve toplam yüzde argüman olarak verilen değerden daha düşükse, öğrenci veritabanından bir kaydı silmek için 02:06.090 --> 02:09.240 bu API'yi yeniden kullanacaktır. 02:10.080 --> 02:10.500 Tamam. 02:10.770 --> 02:15.060 Ve geliştiricinin işi bittiğinde, öğrenci veritabanı muteksinin kilidini açacağı açıktır. 02:16.290 --> 02:21.300 Hayır, yazan geliştirici değil, Bu API'yi bir olarak adlandıralım. 02:21.600 --> 02:24.210 Ve bu API'yi API aracı olarak adlandıralım. 02:24.900 --> 02:32.940 Dolayısıyla API one'ı yazan geliştirici, API'nin dahili uygulamasının ne olduğunu görmekle de uğraşmayacaktır. 02:33.600 --> 02:41.850 Basitçe iki numaralı API'yi çağırmak istiyor çünkü iki numaralı API'nin öğrenci kaydını bu öğrenci 02:41.850 --> 02:45.210 veritabanından sileceğini biliyor. 02:46.140 --> 02:46.530 Tamam. 02:46.920 --> 02:54.480 Böylece iki numaralı API, birinci API'yi yazan geliştiricinin kara kutu aracı gibi çalışacaktır. 02:55.320 --> 02:55.680 Tamam. 02:56.100 --> 02:58.560 Ve şirkette olan da budur. 02:58.560 --> 03:05.460 Bir kod yazdığınızda, önceden yazılmış API'leri çağırırsınız ve çoğu zaman sadece bu API'lere girdinin 03:05.460 --> 03:11.940 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 03:11.940 --> 03:13.410 bilirsiniz. 03:13.770 --> 03:14.190 Tamam. 03:15.920 --> 03:21.560 Şimdi bu yaklaşımla, bir sorun olduğunu görebilirsiniz, sorun basitçe 03:21.560 --> 03:30.980 ş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 03:30.980 --> 03:35.330 yine aynı sessizliği burada kilitler. 03:35.930 --> 03:38.270 Yani aynı muteks tekrar günlüğe kaydediliyor. 03:38.870 --> 03:43.850 Bu, bu talimatta bir çıkmaza girileceği anlamına gelir. 03:46.210 --> 03:46.600 Tamam. 03:46.870 --> 03:48.650 Nedeni de basit. 03:49.030 --> 03:52.330 Aynı yeni vergi, aynı tehditle tekrar kayıt altına alınıyor. 03:54.390 --> 03:59.820 Şimdi, bu API için basit çözümün, öğrenci kaydının tamamen yeni bir API olduğuna 03:59.820 --> 04:02.670 inanmanız olduğu iddia edilebilir. 04:03.210 --> 04:08.740 Ve bu API'nin amacı basitçe öğrenci kaydını öğrenci veritabanından silmektir. 04:08.760 --> 04:16.770 Elbette, ancak API'nin bu yeni sürümünde, yeni saldırılarda herhangi bir öğrenci veritabanı kilidini kaydetmeyecektik. 04:17.700 --> 04:25.390 Ş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 04:25.390 --> 04:31.650 bir öğrenci veritabanı muteksini kilitlemeden öğrenci veritabanından bir öğrenci kaydını 04:31.650 --> 04:35.220 silme zahmetine girdiğini görebilirsiniz. 04:36.120 --> 04:43.020 Ve unutmayın, bu API'nin tanıtılmasının tek bir nedeni vardı, o da bu API'nin yeni vergiyi 04:43.020 --> 04:47.310 zaten kilitleyen API'lerden çağrılabilmesiydi. 04:48.920 --> 04:49.310 Tamam. 04:49.610 --> 04:55.340 Yani bu geçerli bir çözümdür, bu çözümle ilgili tek sorun, her işlev için yinelenen bir 04:55.340 --> 04:57.410 işlev yazmanız gerekmesidir. 04:57.710 --> 05:03.300 Bu iki fonksiyon arasındaki tek fark, fonksiyonun bir versiyonunun sessiz ekseni kilitlemesi, 05:03.300 --> 05:10.970 diğer versiyonunun ise aynı işlemi kilitleme veya kilit açma ve erişimi sınırlama olmadan yapmasıdır. 05:11.420 --> 05:14.090 Bu da kod tekrarına yol açar. 05:14.840 --> 05:19.550 Bu geçerli bir çözümdür, ancak bu çözümle birlikte çok sayıda kod tekrarı sorunu ortaya çıkar. 05:20.090 --> 05:26.960 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 05:26.960 --> 05:29.600 her zaman gözünüzde canlandırabilirsiniz. 05:30.920 --> 05:33.950 Şimdi aynı senaryoyu tekrar görselleştirelim. 05:33.950 --> 05:40.850 Ancak bir dakika ekseni yerine, bu yeni vergilerin özyinelemeli yeni vergiler olduğunu varsayalım. 05:42.000 --> 05:47.820 Dolayısıyla, eğer bu yeni vergiler elbette programda kullanılan yeni vergiler ise, o zaman 05:47.820 --> 05:52.260 bu iki API mükemmeldir, kendi kendini tamamlar ve hiçbir hata yoktur. 05:53.480 --> 05:53.870 Tamam. 05:54.890 --> 06:01.280 İçerideki tehdit bu API'yi çağırdığında, muteks burada kaydedilir, buna bir numaralı yuva diyelim ve aynı sessiz 06:01.280 --> 06:04.940 erişim burada aynı iş parçacığı tarafından kaydedilir. 06:05.480 --> 06:05.870 Tamam. 06:06.170 --> 06:11.420 Ve tabii ki, dediğim gibi, bu özyinelemeli kök erişiminin kilidi, aynı iş parçacığı, aynı özyinelemeli mutasyonlar 06:11.420 --> 06:17.360 tarafından kaydedildiği ve burada kaydedildiği ve aynı özyinelemeli dizinler tarafından kaydedildiği ve burada da kaydedildiği 06:17.360 --> 06:18.290 kadar açılmalıdır. 06:19.400 --> 06:25.550 Ve gerileyici yeni bir vergi olduğu için, 381, CPA'dan bir program yürütmeye başladığında bu 06:26.120 --> 06:31.100 talimatta kilitlenme durumuna girmeyecek, öğrenciyi kaldıracaktır. 06:32.910 --> 06:40.290 Yeni kazılar, aynı API'nin muteksi zaten kilitleyen başka bir API'den çağrılma olasılığının olduğu 06:40.290 --> 06:46.620 senaryolarda işleri basitleştirir, bu durumlarda özyinelemeli kök erişimi kullanmanız 06:46.620 --> 06:47.820 gerekir. 06:48.960 --> 06:51.120 Yani bu, yeni vergilerin tekrarlandığı bir durumdu. 06:51.120 --> 06:56.900 Umarım bu örnekle, özyinelemeli Metaxa'ları neden ve nerede kullanmanız gerektiği ve normal mutex'in hangi 06:56.910 --> 07:01.020 senaryolarda başarısız olacağı çok net bir şekilde anlaşılmıştır.