WEBVTT

1
00:05.410 --> 00:11.140
Bir önceki ders videosunda, tüketici iş
parçacığı için sözde kodun nasıl
yazılacağını

2
00:11.140 --> 00:17.590
ve bir iş parçacığı üretmek için sözde
kodun nasıl yazılacağını öğrendik, böylece

3
00:17.590 --> 00:21.910
tüketici ve üretici buğday ve sigma
gözlerini kullanarak birbirleriyle
koordine olabilirler, değil

4
00:24.680 --> 00:32.180
mi? Tüketici tarafında S1, S2, S3, S4, S5
başlık numaralarını tartışacağız ve

5
00:32.180 --> 00:39.500
üretici tarafında S6, S7, S8, S9
sekmelerini tartışacağız ve ayrıca bu

6
00:39.500 --> 00:40.550
üst ve tüketici ve üretici taraflarının
her birinin alaka düzeyini tartışacağız.

7
00:41.390 --> 00:47.330
Ancak üretici ve tüketici iş parçacığı
arasındaki koordinasyonu temsil eden

8
00:47.330 --> 00:50.600
bu iki sözde kod parçasında hala bir
boşluk var.

9
00:51.080 --> 00:57.560
Bu nedenle, yapacağımız bu derste,
boşluğun ne

10
00:57.560 --> 00:58.130
olduğunu ve bu boşluğun nasıl
onarılabileceğini tartışacağız.

11
00:58.790 --> 01:06.500
Hatırlayın, öncelikli hedeflerimizden biri
Q'yu boş bulmaya çalışan tüketicinin

12
01:06.500 --> 01:07.790
kendisini bloke etmesiydi, değil mi? Yani
tüketici, S4 adım

13
01:08.270 --> 01:16.340
numarasını yalnızca kill'in boş olmadığı
garanti edildiğinde çalıştırmalıdır,

14
01:16.670 --> 01:17.030
değil mi? Eğer bir şekilde tüketici
tehdidimiz boş

15
01:17.570 --> 01:25.130
bir kuyrukta S4 numaralı adımı
çalıştırırsa, o zaman

16
01:25.370 --> 01:28.250
programın bu özel durumunu sorunlu durum
olarak değerlendiririz.

17
01:28.640 --> 01:29.030
Değil mi? Şimdi bu derste, size üretici ve
tüketici

18
01:30.290 --> 01:35.990
iş parçacığının bu sudoku koğuşuyla,
tüketicinizin boş bir

19
01:35.990 --> 01:43.940
Q üzerinde S4 adım numarasını nasıl
yürütebileceğini göstereceğim.

20
01:45.870 --> 01:52.350
Başlangıç olarak, diyelim ki programımızda
ya da sürecimizde 381

21
01:52.350 --> 01:55.180
ve üçüncüsünü tüketici eğilimine sokmak
zorundayız, değil mi? Bu

22
01:55.500 --> 01:59.070
programda herhangi bir sayıda üretici ve
tüketici tehdidi olabilir.

23
01:59.370 --> 02:04.830
Boşluğu açıklamak için iki tüketici
tehdidi olduğunu düşünelim, değil

24
02:06.110 --> 02:08.600
mi? Ve tabii ki, bu bir üretici tehdidi.

25
02:11.140 --> 02:17.140
Şimdi, trad tüketicisinin çarpıklıktan bir
veri öğesi tüketmek istediğini,

26
02:17.140 --> 02:19.870
bu nedenle tüketici eğiliminin bir
numaralı adımı gerçekleştirdiğini
varsayalım.

27
02:20.170 --> 02:22.280
Kuyruğu boş bulur.

28
02:22.300 --> 02:26.770
Bu nedenle, tüketici tehdidi üçüncü adımda
bir blok olacaktır.

29
02:27.250 --> 02:27.640
Doğru.

30
02:28.750 --> 02:35.890
Yani tüketici tehdidi sözde kodunu bir
bağlamında tartışıyoruz ve

31
02:35.890 --> 02:39.520
S3 adımında bloke olan tehdittir, değil
mi? Şimdi, tehdit

32
02:42.100 --> 02:48.070
üç numaralı adımda bile engellendiğinden,
şimdi, üretici iş parçacığınızın

33
02:48.070 --> 02:57.070
CPU'yu doğru aldığını ve altı numaralı
adımı yürütmeye başladığını

34
02:57.070 --> 02:58.840
ve kuyruğun kapasitesine kadar dolu
olmadığını bulduğunu varsayalım.

35
02:59.110 --> 03:01.420
Bu nedenle bir veri öğesi oluşturur.

36
03:01.660 --> 03:05.940
Ve veri öğesini oluşturduktan sonra, bu
öğeyi bu kuyruğa yerleştirir.

37
03:06.610 --> 03:07.000
Değil mi? Öyleyse bu kutuyu üretici iş
parçacığı tarafından kuyrukta

38
03:07.300 --> 03:14.170
bulunan bir veri öğesi olarak temsil
edelim ve ardından

39
03:14.170 --> 03:21.580
şu anda zaten engellenmiş olan 3D'ye bir
sinyal gönderildiği

40
03:21.580 --> 03:23.590
için sekiz numaralı adımı yürüten bir iş
parçacığı üretelim.

41
03:23.600 --> 03:32.080
Bu sinyal üzücü olur olmaz, anlaşma blog
durumundan yürütmeye hazır duruma geçer.

42
03:33.470 --> 03:33.830
Doğru.

43
03:34.460 --> 03:43.700
Ancak 31, üretici Ted muteksi serbest
bırakana kadar çalıştırılmayacaktır, bu
nedenle

44
03:43.700 --> 03:46.490
32'nin dün gece adım numarasını
çalıştırarak bu saldırıları
gerçekleştirdiğini varsayalım.

45
03:47.150 --> 03:47.510
Tamam mı? Şimdi üretici S9 adımının
yürütülmesini

46
03:49.650 --> 03:57.150
bitirmeye çalıştığı anda sorun ortaya
çıkıyor.

47
03:57.660 --> 04:05.610
Şimdi süreçte 31 ve 33 numaralı iki iş
parçacığı daha

48
04:05.610 --> 04:07.110
var ve bunlar yürütülmek üzere CPO'ya
tahsis edilebilir, değil mi?

49
04:07.530 --> 04:11.310
Her iki tehdit de Stephen A. üç CPU
tarafından yürütülebilir.

50
04:11.580 --> 04:18.180
Şu anda sorun, CPU'nun 31 yerine 333'ü
kullanması durumunda ortaya çıkacaktır.

51
04:18.510 --> 04:18.900
Doğru.

52
04:19.350 --> 04:26.640
Dolayısıyla, çekirdek zamanlama
politikasına veya tehdit zamanlama
politikasına göre CPU

53
04:26.640 --> 04:28.650
tarafından hangi iş parçacığının
zamanlanacağı üzerinde bir kontrolünüz
yoktur.

54
04:28.980 --> 04:33.870
İşletim sisteminiz CPU üzerinde
yürütülecek iş parçacıklarından herhangi
birini seçebilir.

55
04:34.170 --> 04:34.530
Doğru.

56
04:34.890 --> 04:39.810
Ve bu durumda, Stephen A.'yı çeken şey,
üçünün yürütülmeye hazır olmasıdır, değil
mi?

57
04:41.340 --> 04:47.160
Şimdi, albay olduklarını varsayalım,
işletim sistemimiz yürütmek için 33'ü
seçer, değil mi? Ve

58
04:47.640 --> 04:55.710
333'ün bir tüketici tehdidi olduğunu zaten
biliyoruz, bu yüzden şimdilik SE numaralı
durakta,

59
04:55.980 --> 05:01.950
94, bunun dokuz numaralı adımdan sonra
yürütülen bir adım olduğu anlamına gelir.

60
05:02.550 --> 05:04.320
Ama adım numarasından önce.

61
05:04.320 --> 05:05.910
Doğru mu? Diyelim ki programınızın bu
noktasında, fiyatların

62
05:08.630 --> 05:14.870
üçü olan başka bir tüketici eğilimi
kuyruğu tekrar

63
05:15.140 --> 05:19.370
boşaltıyor, değil mi? Unutmayın, kuyrukta
bir eleman var

64
05:19.730 --> 05:26.210
ve kuyruğun bu belirli elemanını tüketen
tüketici

65
05:26.210 --> 05:31.130
33'tür ve kuyruk tekrar boş duruma
getirilir.

66
05:32.910 --> 05:40.740
Dolayısıyla, 383 numaralı üye, 382 dokuz
numaralı adımı tamamladığında ve çekici
bire CPU

67
05:40.740 --> 05:46.950
tahsis edilmediğinde bu eylemi
gerçekleştirir, yani 31'e herhangi bir
zamanda CPU tahsis edilebilir.

68
05:47.250 --> 05:55.110
Ancak öyle oldu ki işletim sisteminiz
çalıştırmak için 31 yerine başka bir 33
seçti.

69
05:55.740 --> 05:58.020
Yani 31 henüz infaz edilmedi.

70
05:58.020 --> 05:59.460
Adım numarası dörttür.

71
06:00.450 --> 06:04.980
Şimdi, üç numaralı tehdit gerçekleştikten
sonra, adım numarası 94'tür.

72
06:05.640 --> 06:12.120
Şimdi 31'in CPU'yu aldığını ve S4 adım
numarasını yürüttüğünü varsayalım.

73
06:13.080 --> 06:13.470
Değil mi? Şimdi 381 numaralı tüketicimizin

74
06:13.860 --> 06:21.330
boş bir kuyruk tükettiğini görebilirsiniz,
bu

75
06:21.330 --> 06:22.830
da sorunumuza göre istenmeyen bir
durumdur.

76
06:22.830 --> 06:32.100
İfade veya hedef düpedüz S4 numaralı
adımın boş bir kuyrukta

77
06:32.100 --> 06:34.560
yürütülmesiyle sonuçlanır ki bu da
varsayımımıza göre problemin durumudur.

78
06:34.800 --> 06:35.190
Doğru.

79
06:36.300 --> 06:42.390
Şimdi, tüketici ticaretinin boş bir
kuyrukta dört

80
06:42.660 --> 06:44.190
numaralı adımı engellediği çözüm
düşüncemizi uygulamamız gerekiyor.

81
06:45.120 --> 06:52.320
Dolayısıyla bu sorun, tüketici eğiliminin
sözde kodunda yapabileceğiniz

82
06:52.320 --> 06:53.370
çok küçük bir akor değişikliği ile basitçe
çözülebilir.

83
06:54.150 --> 06:56.640
Çözüm çok basit ve anlaşılırdır.

84
06:57.060 --> 07:04.890
Sinyali aldıktan sonra uyanan tüketici iş
parçacığı, kuyruğu gerçekten işlemeden
önce

85
07:04.890 --> 07:07.480
yüklem koşulunu tekrar kontrol etmelidir,
değil mi? Yani bu basitçe, tüketici

86
07:08.220 --> 07:14.280
işlem bu sinyali aldığında ve tüketici
işlem gerçekten yürütmeye başladığında, S4

87
07:14.280 --> 07:21.600
adımını gerçekleştirmek için bu yüklem
koşulunu tekrar sürüklemesi gerektiği
anlamına gelir.

88
07:22.560 --> 07:29.250
Yani burada yapabileceğiniz basit bir
küçük akor değişikliği, if

89
07:29.250 --> 07:32.790
koşulu yerine while koşulunu yazmanız
gerektiği anlamına gelir.

90
07:33.180 --> 07:34.260
İşte bu kadar.

91
07:35.840 --> 07:42.170
Tüketici bloktan Steed'e her yürütmeye
başladığında,

92
07:42.170 --> 07:43.100
yüklem koşulunu tekrar kontrol edecektir.

93
07:43.580 --> 07:50.720
Ve eğer küpü boş bulursa, çünkü 31 işlem
yapmadan önce başka bir tüketici iş

94
07:50.720 --> 07:56.720
parçacığı küp üzerinde işlem yapmışsa, o
zaman 31 koşul değişkeni üzerinde tekrar
bloke olur.

95
07:57.200 --> 08:02.930
Bu da basitçe, antlaşmanın boş bir
kuyrukta asla Adım S4'ü yürütemeyeceği
anlamına gelir.

96
08:03.470 --> 08:09.620
Şimdi S2 adımındaki tüketici iş parçacığı
sözde kodunda, eğer bunu wild deyimiyle

97
08:09.620 --> 08:15.890
değiştirirseniz, tüketici tehdidi ve koşul
değişkeninde iki parçayı senkronize
etmeniz gereken

98
08:15.890 --> 08:19.010
tüm çok iş parçacıklı programlar için
mükemmel bir sözde kod olur.

99
08:19.280 --> 08:24.800
Üretici ve tüketici iş parçacığı için
tamamen aynı sözde kodu yazmalısınız,
değil mi?

100
08:25.460 --> 08:31.380
Şimdi bir sonraki slaytta ilerleyerek,
bunun tüketici gururu için mükemmel bir
sözde kod

101
08:31.380 --> 08:36.110
olduğunu ve sağ tarafta da üretici iş
parçacığı için mükemmel bir sözde kod

102
08:36.410 --> 08:40.520
olduğunu görebilirsiniz, değil mi? Yani
bunlar, uygulamanın problem ifadesi
itibariyle genel sözde kodlardır.

103
08:40.760 --> 08:45.560
Tabii ki, buraya bir yüklemi temsil eden
bir fonksiyon

104
08:47.150 --> 08:53.360
yazmanız gerekiyor, değil mi? Ve burada
Vaikka üzerinde kritik

105
08:53.360 --> 08:54.830
bölümün yürütülmesini temsil eden
uygulamaya özel bir iş yapmanız

106
08:55.130 --> 09:01.180
gerekir, değil mi? Yani bu fonksiyon, yeni
tüketici iş

107
09:01.190 --> 09:02.030
parçacığı uyandığında çalıştırılacak
uygulamanızın kritik bölümünü temsil eder.

108
09:02.990 --> 09:08.480
Yani bu genel sözde koddur ve iş
parçacığı,

109
09:08.480 --> 09:09.560
senkronizasyon sorunu ve çözümü kodlarken
aynı modeli izleyin.

110
09:10.250 --> 09:16.040
Bu, tutarlı ve somut olan üretici ve

111
09:16.040 --> 09:16.700
tüketici iş parçacıkları arasındaki
senkronizasyon türüdür.

112
09:17.150 --> 09:22.790
Çoğu iş parçacığı senkronizasyon problemi
standart üretici ve tüketici

113
09:23.120 --> 09:23.480
problemlerine ayrıştırılabilir, değil mi?
Bir kerede iş parçacığı

114
09:23.990 --> 09:30.230
senkronizasyonu yazarken, bu sözde kodları
tekrar tekrar yazacağınızı

115
09:30.230 --> 09:36.630
fark edeceksiniz, çünkü çoğu iş parçacığı
senkronizasyon problemi

116
09:36.650 --> 09:42.110
günün sonunda minimum boyutta üretici
tüketici problemlerine ayrıştırılabilir.

117
09:42.470 --> 09:47.780
Dolayısıyla, iki iş parçacığını senkronize
etmeniz gerektiğinde ve bu iki iş
parçacığı

118
09:47.780 --> 09:54.230
aslında aynı kaynak için rekabet ettiğinde
ve iş parçacıkları üretici tüketici iş

119
09:54.230 --> 10:01.040
parçacıkları olarak sınıflandırılabilecek
nitelikte olduğunda, aklınızda ikinci bir
düşünce olmadan, bu iki

120
10:01.040 --> 10:03.890
sözde kodu kullanarak iki iş parçacığını
senkronize etmeyi düşünmelisiniz, değil
mi?