WEBVTT 00:07.600 --> 00:11.140 Evet arkadaşlar, şimdi de kilitlenmeleri tartışacağız. 00:11.440 --> 00:16.150 İş parçacığı senkronizasyonu söz konusu olduğunda, kilitlenme karşılaşacağınız en popüler 00:16.150 --> 00:17.560 terimlerden biridir. 00:17.740 --> 00:23.390 Yani kilitlenme, burada kimsenin olmadığı bir durumdur, kimse sürecinizin herhangi bir iş parçacığı anlamına gelmez. 00:23.410 --> 00:29.920 Yani kilitlenme, bir sürecin hiçbir iş parçacığının ilerleme kaydetmediği ve bu kilitlenme durumuna 00:29.920 --> 00:35.060 katılan tüm iş parçacıklarının sonsuza kadar engellendiği bir durumdur. 00:35.080 --> 00:38.020 Buradaki sonsuza kadar terimine dikkat edin, değil mi? 00:39.010 --> 00:41.170 Yani bu kilit kalıcı bir durumdur. 00:41.170 --> 00:47.080 Programınızda bir kez meydana geldiğinde, programınızı öldürüp yeniden başlatmaktan başka bir 00:47.080 --> 00:48.700 çözüm yolunuz yoktur. 00:49.490 --> 00:54.000 Dolayısıyla, tehditler yanlış bir şekilde senkronize edilirlerse kilitlenmeye maruz kalabilirler. 00:54.020 --> 01:00.590 Şimdi, paylaşılan bir kaynak için rekabet eden sürecin birden fazla iş parçacığının hangi durumda kilitlenme 01:00.590 --> 01:03.350 durumuna girebileceğini anlayalım. 01:05.090 --> 01:07.990 Sağ taraftaki bir resim binlerce kelime söyler. 01:08.000 --> 01:11.630 Bu, bir çıkmaz durumunu tasvir eden gerçek bir dünya durumudur. 01:11.630 --> 01:12.260 Değil mi? 01:12.500 --> 01:19.090 Şimdi bir süreçteki iş parçacıklarınızın hangi durumda kilitlenmeye maruz kalabileceğini anlamaya çalışalım. 01:19.100 --> 01:21.140 Diyelim ki bir süreciniz var. 01:21.170 --> 01:25.070 P Ve bu süreçte P bazı R2 kaynaklarına sahip olursunuz. 01:25.100 --> 01:31.610 Bu kaynak, R2 işleminizin bazı veri yapıları veya başka bir kaynak olabilir. 01:31.610 --> 01:37.010 Örneğin, işleminiz bir SQL veritabanına erişmeye çalışıyor olabilir, değil mi? 01:37.010 --> 01:42.080 Yani R2, işleminizin erişmeye çalıştığı kaynaklardan birini temsil ediyor, değil mi? 01:42.440 --> 01:45.800 Ve benzer şekilde, bir kaynağımız daha var, diyelim ki R1. 01:45.800 --> 01:52.390 Yani R1 ve R2, bir sürecin iş parçacıklarının erişmeye çalıştığı iki farklı kaynaktır. 01:52.400 --> 01:59.990 Şimdi sürecinizin T1 adında bir iş parçacığına sahip olduğunu ve T1 iş parçacığının R2 kaynağını zaten günlüğe kaydettiğini 01:59.990 --> 02:01.790 varsayalım. 02:01.820 --> 02:02.480 Doğru. 02:02.480 --> 02:06.540 Bu, T1 iş parçacığının R2 kaynağını kullandığı anlamına gelir. 02:06.540 --> 02:07.260 Doğru. 02:08.530 --> 02:09.220 Antlaşma. 02:09.220 --> 02:16.830 R2 kaynağı üzerinde pthread mutex lock çağrısı zaten yapılmış ve bu çağrı başarıyla tamamlanmıştır. 02:16.840 --> 02:21.370 Yani bu basitçe R2 kaynağının T1 iş parçacığı tarafından kilitlendiği anlamına gelir. 02:21.640 --> 02:26.020 Benzer şekilde, süreçte bir iş parçacığı daha olduğunu varsayalım. 02:26.020 --> 02:28.360 T2 ipliğini ve ipliği söyleyin. 02:28.390 --> 02:32.940 T2 zaten r1 kaynağı üzerinde başarılı bir şekilde kilit kazanmıştır. 02:32.950 --> 02:33.670 Doğru. 02:34.870 --> 02:40.650 R1 kaynağının kendi muteksine ve R2 kaynağının kendi muteksine sahip olduğunu görebilirsiniz. 02:40.660 --> 02:44.770 Mutex'in bir iş parçacığının değil, bir kaynağın özelliği olduğunu unutmayın. 02:45.980 --> 02:51.920 Eğer kaynak bir dolap gibiyse, ilgili muteks de o dolabın anahtarı gibidir. 02:52.220 --> 02:55.100 Şimdi bu durum söz konusuyken, tehdit de budur. 02:55.150 --> 03:01.370 T1 zaten R2 kaynağını kilitlemiştir ve T2 iş parçacığı zaten R1 kaynağını kilitlemiştir. 03:01.490 --> 03:09.980 Şimdi T2 iş parçacığının yürütme akışını gerçekleştirdiğini ve R2 kaynağı üzerinde de bir kilit vermek istediğini 03:09.980 --> 03:11.530 varsayalım. 03:11.540 --> 03:12.350 Doğru. 03:12.380 --> 03:19.010 Bir sürecin bir iş parçacığının aynı anda bir sürecin birden fazla kaynağına kilit vermek istemesi 03:19.010 --> 03:20.630 çok olasıdır. 03:20.810 --> 03:27.890 Diyelim ki T2 iş parçacığı R2 kaynağının muteksi üzerinde bir çağrı iş parçacığı muteks kilidi çağırıyor. 03:27.920 --> 03:28.760 Doğru. 03:29.060 --> 03:36.020 Şimdi R2 kaynağı zaten T1 iş parçacığı tarafından kilitlendiği için ne olacak, bu sadece T2 iş parçacığının zaten kilitli 03:36.020 --> 03:39.980 olan bir muteksi kilitlemeye çalıştığı anlamına gelir. 03:40.010 --> 03:43.580 Bu da t2 iş parçacığının engellenmiş duruma geçeceği anlamına gelir. 03:43.580 --> 03:44.250 Doğru. 03:44.270 --> 03:49.020 İş parçacığı engellenmiş duruma geçtiğinde, iş parçacığı herhangi bir işlem yapamaz. 03:49.840 --> 03:54.450 Benzer şekilde, 31 R1 kaynağı üzerinde kilit sahibi olmak ister. 03:54.460 --> 03:55.240 Doğru. 03:55.240 --> 04:03.250 Ve bunun için 31, R1 kaynağı üzerinde Pthread mutex lock API'sini çağırır, ancak R1 kaynağı zaten T2 iş parçacığı tarafından 04:03.250 --> 04:04.900 kilitlenmiştir. 04:04.930 --> 04:09.540 Bu sadece T1 iş parçacığının da engellenmiş bir durumda olacağı anlamına gelir. 04:09.550 --> 04:10.330 Doğru. 04:11.050 --> 04:16.270 Şimdi tüm bu tabloda çıkmazın oluştuğunu görebilirsiniz. 04:16.300 --> 04:22.300 T1 ve T2 iş parçacığı olan her iş parçacığı diğer iş parçacığının kaynağı serbest bırakmasını beklemektedir. 04:22.330 --> 04:23.050 Doğru. 04:23.440 --> 04:30.310 Yani bir bakıma bu iki iş parçacığının her birinin diğerinin kaynağı serbest bırakmasını beklediğini ve bu nedenle bir 04:30.310 --> 04:33.220 tür kilitlenme durumu olduğunu görebilirsiniz. 04:33.220 --> 04:35.410 Asla ilerleyemezler. 04:36.010 --> 04:40.840 Şimdi, programınızda kilitlenmenin nasıl meydana gelebileceğini anladıktan sonra, bir sonraki 04:40.840 --> 04:46.450 ders videosunda, bir sürecin iş parçacıklarının kilitlenme durumuna maruz kalması için aynı anda gerçekleşmesi 04:46.450 --> 04:51.170 gereken minimum koşul kümesinin ne olduğunu resmi olarak anlayacağız.