WEBVTT 1 00:05.420 --> 00:12.200 Şimdi, uygulama mantığı görev aracılığıyla yürütüldüğü ve bu görev 2 00:12.200 --> 00:19.250 de olay döngüsü iş parçacığı tarafından tetiklendiği sürece, çift 3 00:19.250 --> 00:20.030 döngü kullanan uygulamaların kilitsiz olduğu noktasını anlamaya çalışalım. 4 00:20.660 --> 00:26.570 Bu nedenle, en temel düzeyde neden üçlü senkronizasyon ve 5 00:26.570 --> 00:29.810 kilitlemeye ihtiyaç duyulduğunu açıkladığım bir önceki dersi anladığınızı umuyorum. 6 00:30.350 --> 00:37.610 Bu nedenle, olay döngüleri kullanan ve bu nedenle 7 00:37.610 --> 00:38.690 kilitlere ihtiyaç duymadığımız uygulamada aslında bu neden yoktur. 8 00:39.020 --> 00:44.510 Olay döngüsü kullanan uygulamalarda bu noktayı anlamaya çalışalım. 9 00:44.510 --> 00:51.950 Olay döngüsü iş parçacığı adı verilen sadece ve sadece bir iş parçacığı 10 00:51.950 --> 00:54.020 vardır ve tüm uygulama kodunu görev aracılığıyla yürüten bu iş parçacığıdır. 11 00:54.650 --> 00:55.040 Tamam. 12 00:55.520 --> 00:59.930 Yani sistemde sadece ve sadece bir iş parçacığı vardır, bu da bir döngü iş parçacığıdır. 13 01:00.470 --> 01:05.600 Peki bu, neden herhangi bir kilitlemeye ihtiyaç duymadığınızın ilk ve açık 14 01:05.960 --> 01:11.480 nedenidir? Çünkü olay döngüsü kullanan uygulamanız genellikle iş parçacıklı bir uygulamadır. 15 01:12.440 --> 01:17.690 Aynı veri kaynağına erişmek için yarışan birden fazla zaman yoktur. 16 01:19.350 --> 01:20.700 Peki neden kilitlemeye ihtiyacınız var? 17 01:22.440 --> 01:26.190 Ancak bu sebep yeterli değildir. 18 01:27.120 --> 01:34.100 Bunu, beni geçen hatalı döngülerden yararlanan birim transit sistemlerinde görebilirsiniz. 19 01:34.110 --> 01:41.250 Yani T1 görevinden D2 görevine ve bunu göstermek için 20 01:41.250 --> 01:42.990 size daha önce bir yükleme indirme örneği göstermiştim. 21 01:44.650 --> 01:51.250 Ve bu örnekte, yükleme görevi ve indirme görevi olmak üzere iki görev arama yoluyla gerçekleştiriliyordu. 22 01:52.970 --> 01:55.010 Şimdi soru şu. 23 01:55.340 --> 02:01.310 Ve üniter bir sistemde bile, kulenin değiştiği sistemde, bağlam değiştirmeye benzer 24 02:01.310 --> 02:07.220 bir şey olduğu ve buna görev değiştirme adı verildiği için, 25 02:07.220 --> 02:08.180 görevler arasında senkronizasyon için günlüklere ihtiyacımız olacağı anlamına mı geliyor? 26 02:09.290 --> 02:09.650 Tamam. 27 02:10.190 --> 02:17.030 Dolayısıyla, birleşik bir kimlik sisteminde, olay döngülerini kullanmak bana bir anahtar attı ve bu görevi 28 02:17.030 --> 02:22.730 kapatma görev değiştirme olarak adlandırılırken, iş parçacıkları arasındaki normal geçiş bağlam değiştirme olarak adlandırılır. 29 02:24.410 --> 02:29.450 Şimdi soru şu ki, bir anahtarlama olduğuna göre, bu nedenle kilitlere ihtiyacımız 30 02:29.870 --> 02:35.750 var mı? Olay döngüsü kullanan uygulamanın benzersiz bir hedef uygulama olduğu açıktır. 31 02:36.230 --> 02:39.020 Ancak bu uygulamalarda bir de görev değiştirme vardır. 32 02:39.500 --> 02:42.270 Peki bu görev değişimi nedeniyle kilitlere 33 02:42.290 --> 02:43.220 ihtiyacımız var mı? Asıl soru bu. 34 02:43.940 --> 02:48.560 Yani cevap, görev değişiminin kontrollü bir şekilde gerçekleşmesidir. 35 02:49.160 --> 02:55.520 Kontrollü moda dediğimde, bunun geliştiricinin elinde olduğu anlamına geliyor. 36 02:55.520 --> 02:59.960 Mevcut görevine hakim olmayı ve yeni bir görev yüklemeyi sever. 37 03:01.580 --> 03:08.090 İndirme yükleme örneğini analiz ederseniz, olay döngüsünün yükleme görevini yürüttüğünü varsayalım. 38 03:08.900 --> 03:13.400 Dolayısıyla, bu göreve hakim olan ve olaya neden olan bu yazılı ifadedir. 39 03:13.440 --> 03:20.480 Loop, indirme görevi olan yeni göreve geçmeye çalıştı, böylece 40 03:20.480 --> 03:22.930 mevcut görev baskın olduğunda geliştiricinin eli olduğunu görebilirsiniz. 41 03:22.940 --> 03:26.270 Ancak o zaman uçan tüccar bile yeni görevi över. 42 03:27.260 --> 03:27.650 Tamam. 43 03:28.010 --> 03:34.790 Bu nedenle, devam eden görevleri her zaman sonlandırmak geliştiricinin sorumluluğundadır, 44 03:34.790 --> 03:39.860 böylece uygulama veri yapılarının tutarlı bir durumda bırakılması garanti edilir. 45 03:42.170 --> 03:42.560 Tamam. 46 03:42.770 --> 03:50.600 Bu nedenle, denenen olay döngüsü tarafından yüklendiğinde yeni görevin uygulama veri yapılarını tutarlı 47 03:50.600 --> 03:56.930 bir durumda göreceğinin garanti edildiği bir noktada mevcut geçmişine her zaman hakim olmak 48 03:56.930 --> 04:04.010 geliştiricinin sorumluluğundadır, oysa bağlam durumunda bu nokta değildir, anahtarlama bağımsız iş parçacıkları arasında 49 04:04.010 --> 04:11.840 gerçekleşir, türler sadece bir programın herhangi bir keyfi noktasında istedikleri zaman geçiş yapar. 50 04:13.010 --> 04:20.270 Dolayısıyla, uygulama kodunu yürüten ana itici gücün eşit döngülü bir iş 51 04:20.270 --> 04:24.350 parçacığı olduğu uygulamalarda herhangi bir kilitlemeye ihtiyaç duymamamızın ana nedeni budur. 52 04:25.310 --> 04:30.470 Dolayısıyla, görev sonlandırıldığında, uygulama veri yapılarını 53 04:30.470 --> 04:32.120 tutarsız durumda bırakmamak programın sorumluluğundadır. 54 04:32.690 --> 04:38.000 Ve neden herhangi bir programcı bir dilbilimciden bir notu 55 04:38.000 --> 04:39.470 silmenin ortasındayken o anda yürütülmekte olan bir görevden 56 04:39.920 --> 04:46.670 geri dönsün? Sadece bağlı listeden bir notun silinmesini 57 04:46.670 --> 04:48.050 tamamladığında bir görev fonksiyonundan geri döneceği oldukça açıktır. 58 04:49.040 --> 04:49.430 Tamam. 59 04:51.090 --> 04:57.300 Dolayısıyla, olay döngüsü tarafından yüklenecek yeni görev her zaman uygulama veri 60 04:57.300 --> 05:00.030 yapılarını görüntüleyecek ve durumu tutarlı hale getirecektir ve bu garantilidir. 61 05:00.570 --> 05:05.160 Peki ikinci neden, görev değiştirme olduğu için 62 05:05.370 --> 05:06.530 kilitlemeye ihtiyacımız var mı? Cevap hayır. 63 05:06.540 --> 05:08.490 Hala herhangi bir kilitlemeye ihtiyacımız yok.