WEBVTT 00:06.220 --> 00:10.660 Şimdi çocuklar p thread condition broadcast API'sini tartışacağız. 00:10.840 --> 00:12.610 Bu yüzden önce bunu tartışacağız. 00:12.610 --> 00:18.400 Bu API'nin kullanımı nedir ve daha sonra bu API'nin perde arkasında nasıl çalıştığını tartışacağız. 00:18.730 --> 00:23.830 Adından da anlaşılacağı gibi, bu API aynı koşul değişkeni üzerinde bloke olan birden fazla iş parçacığına sinyal göndermek 00:23.830 --> 00:24.940 için kullanılır. 00:25.210 --> 00:28.400 Şimdi bunu bir örnek yardımıyla anlayalım. 00:28.420 --> 00:35.470 Diyelim ki işleminizde g1 iş parçacığı, T2 ve T3 olmak üzere üç iş parçacığı var. 00:35.500 --> 00:36.400 Değil mi? 00:36.400 --> 00:40.510 Ve bu iş parçacıklarının her biri aynı koşul değişkeni üzerinde engellenir. 00:40.810 --> 00:41.620 Doğru. 00:41.650 --> 00:48.130 Bu nedenle, iş parçacığı koşul yayınının aynı koşul değişkeni üzerinde engellenen birden fazla iş parçacığına sinyal göndermek için kullanılan 00:48.130 --> 00:49.990 bir API olduğunu unutmayın. 00:50.650 --> 00:57.190 Şimdi programınızda T1, T2 ve T3 iş parçacığı aynı koşul değişkeni üzerinde engelleniyor. 00:57.700 --> 00:59.830 Sürecin bir diğer halkası. 00:59.830 --> 01:03.910 Sinyalizasyon iş parçacığı anlamına gelen ts iş parçacığı diyelim. 01:03.940 --> 01:08.090 API p iş parçacığı koşulu sinyalini çağırır. 01:08.680 --> 01:09.550 Özür dilerim. 01:10.150 --> 01:13.870 Bir api p iş parçacığı koşul yayını çağırır. 01:14.230 --> 01:15.040 Doğru. 01:15.040 --> 01:19.150 Bu API'nin argümanı da aynı koşul değişkenidir. 01:19.150 --> 01:19.960 Doğru. 01:20.470 --> 01:26.980 Yani perde arkasında yapacağı şey, aynı koşul değişkeni üzerinde bloke olan bu iş parçacıklarının her birine 01:26.980 --> 01:29.020 sinyal göndermek olacaktır. 01:29.170 --> 01:30.010 Doğru. 01:30.130 --> 01:35.890 Ve tüm bu iş parçacıkları teker teker yürütülmeye devam edecektir, Doğru. 01:35.920 --> 01:43.180 Teker teker derken neyi kastettiğimizi daha ayrıntılı olarak tartışacağız, iş parçacıkları aynı anda 01:43.180 --> 01:46.420 değil, teker teker yürütülmeye devam eder. 01:46.810 --> 01:50.320 Yani bu yayın API'sinin kullanımı budur. 01:50.890 --> 01:57.550 Bu yayın API'sini x, y, z gibi bir nedenle kullanmak istemiyorsanız ve yine de engellenen tüm iş parçacıklarının 01:57.550 --> 02:05.020 yürütmeye devam etmesini istiyorsanız, o zaman p iş parçacığı koşulu sinyal API'sini ayrı ayrı çağırmanız gerekir. 02:05.990 --> 02:08.360 Koşul değişkeninde, değil mi? 02:08.360 --> 02:13.190 Ve aynı koşul değişkeni üzerinde bloke olan üç iş parçacığı olduğundan, bu 02:13.190 --> 02:16.160 API'yi üç kez çağırmanız gerekir, değil mi? 02:16.370 --> 02:23.900 Ve blok iş parçacıklarının engelini kaldırmak ve yürütmeye devam etmek istediği sırayı seçmenin işletim sistemine 02:23.900 --> 02:26.420 bağlı olduğunu zaten biliyoruz. 02:26.450 --> 02:32.360 İş parçacıklarına seçici olarak sinyal vermek kesinlikle programcının kontrolünde değildir. 02:32.360 --> 02:33.140 Doğru. 02:34.220 --> 02:40.820 Benzer şekilde, sinyal iş parçacığı api p iş parçacığı koşul yayınını çağırdığında, bu T1T2T3 iş parçacıklarının 02:40.820 --> 02:46.650 hangi sırayla engellemeyi kaldıracağını ve yürütmeye devam edeceğini söyleyemeyiz. 02:46.670 --> 02:53.210 Her şey işletim sisteminizin zamanlama politikasına bağlıdır; x, y, z gibi bir nedenle hangi iş parçacığının 02:53.210 --> 02:57.560 engelini kaldırıp önce yürütmeye devam edeceğini seçer. 02:57.710 --> 02:58.520 Doğru. 02:58.730 --> 03:02.230 Yani iş parçacığı koşulu yayın API'si bu şekilde çalışır. 03:02.240 --> 03:08.820 Ve programınızda, p thread koşul yayını yerine p thread koşul sinyali kullanırsanız, aynı koşul değişkeninde 03:08.820 --> 03:15.180 engellenen tüm iş parçacıklarının devam ettirildiğinden emin olmak için bu koşul değişkeninde bekleyen 03:15.180 --> 03:19.620 iş parçacığı sayısı kadar sinyal göndermeniz gerekir. 03:19.620 --> 03:20.430 Doğru. 03:22.350 --> 03:22.710 Şimdi. 03:22.710 --> 03:27.720 Daha sonra, p thread condition broadcast API'sinin sahne arkasında nasıl çalıştığını tartışacağız. 03:29.680 --> 03:35.260 Tartışmamıza devam edersek, sürecinizdeki sinyalizasyon iş parçacığı olan dördüncü 03:35.260 --> 03:42.220 iş parçacığının, T1, T2 ve T3 iş parçacıklarının bloke edildiği aynı koşul değişkeni olan bağımsız değişken 03:42.220 --> 03:48.730 koşul değişkeni üzerinde P iş parçacığı koşul yayın API'sini çağırdığını varsayalım. 03:48.760 --> 03:50.140 Şu anda. 03:50.140 --> 03:56.170 Dediğim gibi, programcının T1, T2 ve T3 iş parçacıklarının hangi sırayla uyandırılacağını kontrol 03:56.170 --> 03:58.090 edecek bir kontrolü yok. 03:58.330 --> 04:05.230 Bu yayın API'sinin işleyişini göstermek için, iş parçacıklarının T2, T1 ve T3 sırasına 04:05.230 --> 04:08.380 göre uyandırıldığını varsayalım. 04:08.560 --> 04:09.340 Doğru. 04:10.340 --> 04:16.310 Şimdi bu iş parçacıklarının her birinin bu sırayla nasıl uyandırılacağını adım adım tartışalım. 04:16.310 --> 04:17.840 T2T1T3. 04:17.870 --> 04:22.630 Unutmayın, bu sıra işletim sisteminizin zamanlama politikasına bağlı olarak herhangi bir şey olabilir. 04:22.640 --> 04:27.950 Şimdi bu üç iş parçacığının bu sırayla nasıl uyandırılacağına ilişkin adımları gözden geçirelim. 04:27.950 --> 04:30.020 Yani t iki, t bir ve t üç. 04:30.230 --> 04:38.750 Dolayısıyla, sinyalizasyon iş parçacığı bu API'yi çağırır çağırmaz, üç iş parçacığı da engellenmiş durumdan yürütmeye 04:39.410 --> 04:42.170 hazır duruma geçecektir. 04:42.920 --> 04:43.640 Doğru. 04:45.710 --> 04:51.740 Benzer şekilde, T2 tehdidi de engellenmiş durumdan yürütmeye hazır duruma ve tehdide geçecektir. 04:51.770 --> 04:56.210 T3 de engellenmiş durumdan yürütmeye hazır duruma geçecektir. 04:58.070 --> 05:04.790 Şu anda, işletim sisteminin yürütmeye devam etmek için T2 iş parçacığını seçtiğini varsaydık. 05:05.090 --> 05:14.060 Bu da basitçe T2 iş parçacığının bu mutekse kilitlenen ilk iş parçacığı olacağı ve bu mutekse kilitlenir 05:14.060 --> 05:21.350 kilitlenmez T2 iş parçacığının hazır durumdan yürütme durumuna geçeceği anlamına 05:21.350 --> 05:22.040 gelir. 05:22.190 --> 05:26.600 Yani, yürütmeye devam edecek olan iş parçacığı T2'dir. 05:28.210 --> 05:30.220 Böylece çıktıyı yazdıracaktır. 05:30.250 --> 05:31.020 T 2. 05:31.030 --> 05:31.780 Doğru. 05:32.380 --> 05:38.020 Şimdi, unutmayın, zamanın bu noktasında, iş parçacığını yürüten yalnızca t iki iş parçacığıdır. 05:38.050 --> 05:42.060 T bir ve t üç hala çalışmıyor. 05:42.070 --> 05:42.810 Doğru. 05:42.820 --> 05:52.030 Dolayısıyla, t iki iş parçacığı muteksin kilidini açar açmaz, şimdi t bir ve t üç iş parçacığı bu muteks üzerinde kilit 05:52.030 --> 05:53.860 için yarışacaktır. 05:53.950 --> 05:54.820 Doğru. 05:54.940 --> 06:02.980 Dolayısıyla, sıramıza göre, bu muteks üzerinde kilit alanın t iş parçacığı olduğunu varsayalım. 06:02.980 --> 06:07.930 Böylece t bir iş parçacığı şimdi hazır durumdan yürütme durumuna geçecektir. 06:09.330 --> 06:13.400 Yani bu basitçe, bir sonraki yürütülecek olan iş parçacığının T1 olduğu anlamına gelir. 06:13.410 --> 06:17.190 Böylece t1 iş parçacığını doğru yazdıracaktır. 06:18.340 --> 06:25.750 Ve D1 tehdidi muteksin kilidini açtığında, yürütmeye hazır durumda olan tek iş parçacığı T3 06:25.750 --> 06:32.680 iş parçacığıdır ve hazır durumdan yürütme durumuna geçecek olan T3 iş parçacığıdır. 06:33.690 --> 06:35.940 Doğru, yani tehdit T üç. 06:35.970 --> 06:38.130 Üç tane basacağım. 06:38.130 --> 06:41.010 Ve şimdi de tehdit üç olunca. 06:41.040 --> 06:48.270 Muteksin kilidini açar, tüm tehdit T1T2 ve üç üç kritik bölümlerinin dışındadır. 06:48.900 --> 06:53.640 Tehdit T1, T2 ve T3 kritik bölümlerinin dışına çıktığında, tehdit. 06:53.670 --> 06:56.670 T1, T2 ve T3 eş zamanlı olarak çalışacaktır. 06:56.820 --> 07:03.090 Yani, CPU'nun T1, T2 ve T3 tehditlerine hangi sırayla tahsis edileceği artık işletim sistemi 07:03.090 --> 07:07.200 bağlam değiştirme ve zamanlama politikasına bağlıdır. 07:07.230 --> 07:14.310 T1 kritik bölümün dışında T2 kritik bölümün dışında veya T3 kritik bölümün dışında olan bu dizelerin 07:14.340 --> 07:18.870 hangi sırada yazdırılacağına dair bir şey söyleyemeyiz. 07:18.900 --> 07:25.590 Bunlar, işletim sisteminin blok iş parçacığının yürütülmesini hangi sırada sürdürmeyi seçtiğine bakılmaksızın 07:25.590 --> 07:29.040 herhangi bir sırada yazdırılabilir. 07:29.070 --> 07:32.520 Sinyalizasyon iş parçacığı yayın API'sini çağırdığında. 07:33.350 --> 07:34.100 Doğru. 07:34.100 --> 07:41.570 Dolayısıyla, işletim sisteminiz T2T1 ve T üç sırasındaki iş parçacıklarının engelini kaldırmayı seçtiğinde, 07:41.570 --> 07:47.510 aynı sırayla t iki, t bir ve T üç çıktılarına sahip olacağınız garanti edilir. 07:47.690 --> 07:56.840 Ancak bu dizeler herhangi bir sırada yazdırılabilir çünkü bu dizelerin her biri kritik bölümlerin dışındadır. 07:56.960 --> 07:57.830 Doğru. 07:58.220 --> 08:00.880 Yani bir yayın API'si bu şekilde çalışır. 08:00.890 --> 08:08.560 Yayın API'si aynı koşul değişkeni üzerinde bloke olan tüm iş parçacıklarının blokesini teker teker kaldırır. 08:08.570 --> 08:09.410 Doğru. 08:09.620 --> 08:13.550 Bu konuların her biri kendi kritik bölümlerinden çıkacaktır. 08:14.770 --> 08:18.620 Ve işletim sisteminin seçtiği sıra. 08:18.640 --> 08:19.360 Doğru. 08:19.360 --> 08:24.670 Ancak kritik bölümden her seferinde yalnızca bir iş parçacığının çıkacağı garanti edilir. 08:24.670 --> 08:30.580 Ve kritik bölümün tanımı gereği, aynı anda yalnızca bir iş parçacığı tarafından yürütülen bir kod parçası 08:30.580 --> 08:31.810 olması mantıklıdır. 08:32.470 --> 08:33.160 Doğru. 08:34.320 --> 08:38.160 Dolayısıyla karşılıklı dışlama ilkesi asla ihlal edilmemelidir.