WEBVTT

1
00:06.440 --> 00:12.980
Evet arkadaşlar, şimdi bu ders videosunda,
bazı gerçekçi örneklerin

2
00:12.980 --> 00:15.230
yardımıyla koşul değişkeni ve sessiz
erişim kullanımını uygulayalım.

3
00:15.890 --> 00:21.860
Şimdi bu örnekte, tüketici üçlüsü olarak
adlandırılan birinci anlaşmamızı

4
00:21.860 --> 00:24.770
ve üretici tehdidi olarak adlandırılan
ikinci anlaşmamızı görebilirsiniz.

5
00:25.980 --> 00:26.340
Doğru.

6
00:27.820 --> 00:29.590
Ve bazı veri yapılarımız var.

7
00:30.190 --> 00:35.620
Bu veri yapısının hiçbir işe yaramadığını,
sadece bazı veri elemanları içerdiğini ve

8
00:35.620 --> 00:43.240
31 ve 32'nin bu veri yapısına erişmek için
birbirleriyle yarıştığını varsayalım.

9
00:43.930 --> 00:47.250
Şu anda 31 yaşındaki Sousa, tüketici
olarak çalışıyor.

10
00:47.260 --> 00:53.620
Bu basitçe, 381'in çarpıklıktan bir öğeyi
çıkarmak ve işlemek istediği anlamına
gelir.

11
00:54.370 --> 00:54.700
Doğru mu? Treaty two ise bir

12
00:55.540 --> 01:03.100
üretici iş parçacığıdır ve bazı veriler

13
01:03.100 --> 01:03.490
üretir ve bu verileri kuyruğa iter.

14
01:03.970 --> 01:04.330
Doğru.

15
01:05.140 --> 01:11.080
İşte bu nedenle Treaty one bu kuyruğu

16
01:11.080 --> 01:11.710
tüketirken, Treaty skew'e daha fazla veri
besler.

17
01:11.710 --> 01:17.320
Bu nedenle, 382 üretici ipliği olarak
adlandırılırken, antlaşma tüketici eğilimi
olarak adlandırılır.

18
01:19.880 --> 01:25.420
Artık kabileler arasında paylaşılan bir
kaynak olan bir veri yapısı ipucumuz var.

19
01:26.030 --> 01:30.590
Şimdi, durum yapısı üzerinde karşılıklı
dışlama sağlamak için, bu veri yapısının
kendisiyle

20
01:30.590 --> 01:36.110
ilişkili bir sessiz nesneye sahip olması
ve koşul değişkenine sahip olması gerekir.

21
01:36.110 --> 01:42.650
Ayrıca, koşul değişkeni tüketici ve
üretici tehditlerini senkronize etmek için

22
01:43.590 --> 01:48.570
kullanılır, değil mi? Unutmayın, Murdochs
nesnesi ve koşul değişkenleri

23
01:48.960 --> 01:54.720
veri yapısının özellikleridir, ancak koşul
değişkeninin veri yapısı yerine

24
01:54.720 --> 01:55.920
bir üçlünün özelliği haline geldiği bazı
küçük sapmalar vardır.

25
01:56.160 --> 02:02.130
Ancak durumu basit tutmak için, sadece o
koşul değişkenine gidelim ve
vergilendirelim.

26
02:02.130 --> 02:06.940
Her ikisi de şu anda kaynağın
özellikleridir.

27
02:06.960 --> 02:14.940
Bu örneği açıkladıktan sonra, 381 ve ready
to board'un bu

28
02:14.940 --> 02:17.430
veri yapısından bir eleman üretme ve
tüketme adımlarını gözden geçireceğiz.

29
02:17.440 --> 02:20.310
Q birbirini dışlayan bir şekilde.

30
02:20.910 --> 02:21.300
Doğru.

31
02:21.780 --> 02:25.860
Ve bunun için, tehditler bu koşul
değişkenini ve muteksi kullanır mı?

32
02:26.880 --> 02:34.200
Evet arkadaşlar, sorunumuz şu: 381, Q'dan
bir öğeyi kaldırmaya çalışıyor.

33
02:34.740 --> 02:39.480
Bu unsuru engellenmeden Q'dan başarıyla
çıkarır.

34
02:39.780 --> 02:40.170
Doğru mu? Elbette, 381'in Q'ya yalnızca Q

35
02:41.430 --> 02:49.050
382 hakkı tarafından kullanılmadığında
erişmesi gerekir.

36
02:50.910 --> 02:58.920
Ancak 31 kuyruktan bir eleman çıkarmaya
çalışırsa ancak kuyruk zaten boşsa,

37
02:58.920 --> 03:06.300
bu durumda tüketici iş parçacığımız
engellenmeli ve bir üretici iş

38
03:06.300 --> 03:11.550
parçacığı olan trajedi de kuyruğa yeni bir
eleman itene kadar

39
03:12.030 --> 03:15.150
engellenmiş kalmalıdır, değil mi? İşte
çözmeye çalıştığımız problem cümlesi
budur.

40
03:15.420 --> 03:19.710
Ve daha meşhur olarak, bu problem ifadesi
üretici tüketici problemi olarak
adlandırılır.

41
03:20.280 --> 03:26.430
Dolayısıyla sorun ifadesi, 381'in
kuyruktan bir öğeyi kaldırmaya çalışması
ve

42
03:26.430 --> 03:30.300
kuyruğun zaten boş durumda olması halinde
engellenmesi gerektiği konusunda açıktır.

43
03:30.690 --> 03:31.050
Doğru.

44
03:31.320 --> 03:37.500
Ve tüketici iş parçacığının, üretici iş
parçacığı bir

45
03:37.500 --> 03:39.090
öğe üretip kuyruğa itene kadar bloke
kalması beklenir.

46
03:39.420 --> 03:39.780
Doğru.

47
03:40.890 --> 03:46.800
Şimdi bu mantığı uygulamak için
vergilerden önceki koşul değişkeninin

48
03:46.800 --> 03:49.110
ve yüklemin nasıl bir araya
getirilebileceğini adım adım görelim.

49
03:50.250 --> 03:52.960
Şimdi, yüklem karşılaştığınız yeni bir
terimdir.

50
03:52.980 --> 03:56.020
Yüklemin tam olarak ne olduğunu
açıklayacaktım.

51
03:58.110 --> 04:02.640
Öncelikle tüketici iş parçacığı ile
başlayalım, tamam mı? Tüketici iş

52
04:03.420 --> 04:08.940
parçacığının yapması gereken ilk şey, bir
kuyruk olan paylaşılan kaynak

53
04:08.940 --> 04:10.530
üzerinde bir kilit elde etmektir, değil
mi? Unutmayın, Kuyruk paylaşılan

54
04:11.070 --> 04:16.290
bir kaynaktır ve her iki iş parçacığı da
bu

55
04:16.290 --> 04:20.160
paylaşılan kaynağa erişim talep ederken
karşılıklı dışlama kuralına uymalıdır.

56
04:20.790 --> 04:26.700
Bu nedenle, tüketici işleminin bu kuyruk
üzerinde herhangi bir işlem

57
04:26.700 --> 04:27.240
gerçekleştirebilmesi için öncelikle SKU
üzerinde bir kilit elde etmesi gerekir.

58
04:28.390 --> 04:30.280
Şimdi, çift olduğunu varsayarsak.

59
04:31.860 --> 04:34.710
Bu kuyruk üzerinde kilit elde edebilir.

60
04:35.100 --> 04:40.290
31'in yapacağı bir sonraki şey, bu
kuyruktan bir öğe tüketmektir.

61
04:40.680 --> 04:41.040
Doğru.

62
04:41.520 --> 04:47.520
Ve 31, bu kuyruktaki öğeyi yalnızca kuyruk
boş olmadığında tüketebilmelidir.

63
04:48.210 --> 04:54.420
Bu da basitçe, kuyruk boşsa tüketici
tehdidinin engelleneceği anlamına gelir.

64
04:55.140 --> 04:55.520
Doğru.

65
04:56.460 --> 05:02.100
Böylece, ikinci adımda tüketici tehdidinin
kaynağın durumunu, yani

66
05:02.520 --> 05:04.770
kuyruğun boş olup olmadığını test ettiğini
görebilirsiniz.

67
05:05.070 --> 05:11.280
Dolayısıyla, bu musluk numarasını yalnızca
iki olarak gerçekleştirmek, kaynağın bu
durumunu kontrol etmek anlamına gelir.

68
05:11.730 --> 05:16.980
İş parçacığı tarafından kaynağın durumunu
kontrol etmek için

69
05:16.980 --> 05:17.790
kullanılan koşul, teknik olarak yüklem
olarak adlandırılır.

70
05:18.420 --> 05:20.670
Yani bu koşula yüklem denir.

71
05:22.950 --> 05:29.490
Yani bu sadece ticari senkronizasyon
dünyasında kullanılan teknik bir terimdir
ve

72
05:29.490 --> 05:33.780
yüklem, iş parçacığının kaynağın durumunu
test ettiği koşulu temsil eder.

73
05:34.200 --> 05:38.700
Dolayısıyla, yalnızca adım numarasını
gerçekleştirmek için tüketici ticaretini
satın almak gerekir.

74
05:39.810 --> 05:44.280
Adım S1 bir gereklidir, yani muteksin
kilitlenmesi gereklidir.

75
05:44.700 --> 05:47.910
Şimdi bu muteksin neden gerekli olduğunu
anlıyorsunuz.

76
05:48.450 --> 05:48.810
Doğru.

77
05:49.290 --> 05:56.040
Böylece ticaret, tehdit kaynağın durumunu
kontrol ederken

78
05:56.040 --> 05:56.820
kaynağın durumunu özel olarak kontrol
edebilir.

79
05:57.060 --> 06:01.290
Sürecin başka hiçbir iş parçacığı kaynağın
durumunu değiştirmemelidir.

80
06:01.830 --> 06:05.280
İşte bu nedenle muteks kilitleme
gereklidir.

81
06:05.370 --> 06:12.930
Bir numaralı adım ve yüklem, iş
parçacığına beklemesi gerekip
gerekmediğini söyleyen bir koşuldur.

82
06:13.470 --> 06:13.830
Doğru.

83
06:14.220 --> 06:19.710
Bu örnekte, iki numaralı adım koşulu test
eder

84
06:19.710 --> 06:20.910
ve teknik olarak bu koşula yüklem denir.

85
06:23.250 --> 06:29.700
Şimdi, tüketicinin ipucunu boş olarak
bulduğunu varsayarsak, yani tüketici

86
06:29.700 --> 06:33.990
ticaretinin engellenmesi gereken
tüketiciyi tüketecek hiçbir şeyi yoktur.

87
06:34.410 --> 06:40.200
Üçüncü adımda, tüketici tehdidini
engellemek için ihtiyaç duyduğumuz

88
06:40.500 --> 06:42.570
API be tehdit koşulunu çağırmamızın nedeni
de budur.

89
06:43.200 --> 06:48.930
Problem ifadesinin bir parçası olarak,
üretici tehdidi bu öğeyi

90
06:48.930 --> 06:51.150
boş kuyruğa itene kadar tüketicimizin
bloke kalmaya çalışmasını istiyoruz.

91
06:51.960 --> 06:56.940
Yani burada, bekleme koşulu doğruysa, yani
kuyruk boşsa.

92
06:57.180 --> 07:03.060
Tüketici haklarımız üçüncü adımda
kendisini bir koşul değişkeni olarak bloke
ediyor,

93
07:04.110 --> 07:08.460
değil mi? Yani şimdi üç numaralı adımda,
tüketici engellenmiş durumda.

94
07:08.910 --> 07:09.240
Doğru.

95
07:10.290 --> 07:12.960
Bu da tüketici ticaretinin artık beklediği
anlamına geliyor.

96
07:12.960 --> 07:16.440
Üretici bir öğe üretmeye ve onu kuyruğa
itmeye çalıştı.

97
07:17.280 --> 07:21.420
Bu da basitçe yapımcı Ted'in artık resmin
içine gireceği anlamına geliyor.

98
07:23.710 --> 07:26.620
Şimdi, yapımcı Ted'in kuyruğa bir öğe
itmesi gerekiyor.

99
07:26.650 --> 07:31.450
Bu, üretici iş parçacığının paylaşılan
kaynak üzerinde doğru bir işlem
gerçekleştirdiği anlamına gelir.

100
07:31.900 --> 07:32.230
Doğru.

101
07:32.770 --> 07:38.800
Yani bu basitçe, üretici tehdidinin de
paylaşılan kaynak işaretine

102
07:38.800 --> 07:39.220
karşılıklı olarak özel bir erişime
ihtiyacı olduğu anlamına gelir.

103
07:39.670 --> 07:44.740
Ve bu nedenle, üretici iş parçacığı
muteksin kilitlenmesiyle başlar, değil

104
07:46.410 --> 07:50.610
mi? Unutmayın, tüketici tehdidi blok
durumundadır, şampiyon numarası üçtür.

105
07:50.880 --> 07:55.920
Ve bu özel muteksin perde arkasında
kilidinin açıldığını zaten biliyoruz.

106
07:56.430 --> 08:01.890
Ve bu muteksin kilidi açıldığı için, polis
atad artık

107
08:01.890 --> 08:04.080
altıncı adımda bu muteks üzerindeki kilidi
ele geçirebilir.

108
08:05.130 --> 08:11.160
Şimdi, bir üretici iş parçacığı Q dolu
değilse bunu test

109
08:11.400 --> 08:18.420
edecektir, değil mi? Yani, bu yedi
numaralı adımdır, o zaman

110
08:18.420 --> 08:18.900
üretici işlem bir öğe üretebilir ve onu
kuyruğa itebilir.

111
08:19.500 --> 08:25.620
Dolayısıyla bu özel eylem, paylaşılan bir
kaynak üzerinde gerçekleştirilen doğru bir
işlemi temsil eder.

112
08:25.920 --> 08:26.310
Değil mi? Başka bir deyişle, bu kritik
bölümdür ve

113
08:26.640 --> 08:33.540
üretici iş parçacığı öğeyi başarılı bir
şekilde kuyruğa ittikten

114
08:33.810 --> 08:41.280
sonra, Üretici A'nın tüketici iş
parçacığına sinyal göndererek

115
08:41.280 --> 08:43.680
tüketicinin bir iş parçacığı almaya
çalıştığını bildirdiğini görebilirsiniz.

116
08:43.680 --> 08:45.650
Kuyruğa bir öğe yerleştirdim.

117
08:46.260 --> 08:48.990
İnfazınıza devam edebilirsiniz, değil mi?
Yani bıçaklanma sayısından

118
08:50.140 --> 08:54.940
sonra, ısı bir tehdit üreterek infaz
edildiğinden.

119
08:56.860 --> 09:03.940
Bu koşul değişkenine bir sinyal
gönderilecektir, doğru, bu nedenle iş
parçacığı kontrollerinin

120
09:03.940 --> 09:10.210
üreticisi olan 32, kaynaklar altı numaralı
adımda ayrıcalık sözü verirken adım
numarasının

121
09:10.330 --> 09:15.040
yedi olduğunu alır ve bu yeni öğeyi üretir
ve kuyruğa işaret eder.

122
09:16.300 --> 09:23.320
Ardından üretici Ted, sekiz numaralı
adımda hapsolmuş tüketiciye bir sinyal

123
09:23.590 --> 09:27.460
gönderir ve dokuz numaralı adımda üretici
üçlüsü muteksin kilidini açar.

124
09:27.910 --> 09:28.270
Değil mi? Yani bu

125
09:28.810 --> 09:30.400
API kilidini açmak.

126
09:32.080 --> 09:39.760
Sekiz numaralı adımdan hemen sonra ve
dokuz numaralı adımdan önce,

127
09:39.760 --> 09:42.550
tüketicinin blog durumundan yürütmeye
hazır durumuna geçmeyi denediğini
unutmayın.

128
09:43.030 --> 09:49.330
Ancak dört numaralı adımı yürütecek olan
tüketici, yalnızca üretici iş

129
09:49.330 --> 09:57.250
parçacığı dokuz numaralı adım olan
muteksin kilidini başarıyla açtığında,
ancak

130
09:57.250 --> 09:58.870
S9 numaralı adımdan sonra tüketici etiketi
gerçekten yürütmeye başlar.

131
09:59.770 --> 10:07.510
Dolayısıyla, S4 adımında, tüketici iş
parçacığı yürütmeye devam eder etmez, bu
muteks

132
10:07.510 --> 10:11.980
üzerindeki kilit işletim sistemi
tarafından dahili olarak tüketici iş
parçacığına verilir.

133
10:12.670 --> 10:13.060
Doğru.

134
10:13.480 --> 10:18.640
Ve bu nedenle, yalnızca bu SKU üzerinde
işlem yapabilen tüketici.

135
10:18.640 --> 10:22.030
Yani, artık SKU'dan bir öğe tüketebilir.

136
10:22.480 --> 10:27.880
Yani dördüncü adım, uyandırıldığında
çalışan tüketicinin bulunduğu kritik
bölümdür.

137
10:28.390 --> 10:28.780
Değil mi? Ve son olarak, tüketici

138
10:29.590 --> 10:36.100
işaretten bir öğe tüketirken işi

139
10:36.100 --> 10:37.990
bittiğinde, tüketici muteksin kilidini
açabilir.

140
10:38.440 --> 10:38.830
Değil mi? Yani adım numarasında, X5 bunu

141
10:39.730 --> 10:45.670
yaptığında paylaşılan verilerin kilidini
açıkça açar.

142
10:45.670 --> 10:52.000
Tüm bu hikayede, kritik bölümü temsil eden
adımlar nelerdir diye soracak olursam,

143
10:52.000 --> 10:57.820
basitçe tanımdan yola çıkarak kritik
bölüm, paylaşılan kaynağa eriştiğimiz kod
parçasıdır.

144
10:58.510 --> 11:06.070
Yani üretici tarafındaki bu belirli kod
bölgesi kritik bölümdür ve

145
11:06.070 --> 11:10.180
tüketici tarafındaki bu belirli kod
bölgesi de kritik bölümdür, değil

146
11:11.500 --> 11:18.700
mi? Tüm bu hikayeyi analiz ederseniz,
tüketici ve üreticinin

147
11:18.700 --> 11:21.220
zamanın herhangi bir noktasında karşılıklı
dışlama ilkesine uyduğunu göreceksiniz.

148
11:21.700 --> 11:22.060
Değil mi?

149
11:23.020 --> 11:24.010
Yani rehidrasyon.

150
11:24.010 --> 11:31.450
Bir kez daha, bu muteksin rolü, rakip iş
parçacıklarının paylaşılan kaynağa
karşılıklı

151
11:31.450 --> 11:38.200
olarak özel bir erişime sahip olmalarına
izin vermektir, oysa bu koşul değişkeninin

152
11:38.200 --> 11:41.260
rolü, kaynak hakkı için rekabet eden iş
parçacıkları arasında koordinasyona izin
vermektir.

153
11:41.710 --> 11:47.470
Bu koşul değişkeni sayesinde tüketici
üçlüsü kendini bloke edebildi ve

154
11:47.470 --> 11:51.910
üretici üçlüsü koşul değişkenine sinyal
gönderebildi, değil mi? Ayrıca, şimdi

155
11:53.080 --> 11:59.890
S1'den S9'a kadar olan otobüs musluk
numarasını tamamladık ve

156
11:59.890 --> 12:03.040
eksik damga numarasını iki, dört ve yedi
olarak kapattık.

157
12:03.400 --> 12:03.760
Doğru.

158
12:05.170 --> 12:10.420
Şu an itibariyle, iş parçacığı
senkronizasyonunun en zor kısmı olan

159
12:10.420 --> 12:13.020
koşul değişkeni ve Maraxus ile
çalışıyorsunuz, değil mi? Daha fazla

160
12:13.450 --> 12:19.690
vergi ve koşul değişkeninin nasıl
kullanılacağına dair net bir resim

161
12:19.690 --> 12:25.930
elde ettiğinizde, Monitor, Sema Force vb.
gibi alternatif senkronizasyon

162
12:25.930 --> 12:28.450
için kullanılan daha sofistike ve karmaşık
tertile yapılarını uygulayabileceksiniz.

163
12:29.110 --> 12:35.350
Şimdi bu kod parçasında, bir sonraki

164
12:35.350 --> 12:36.430
derste tartışacağımız bir iyileştirme
kapsamımız var.