Evet arkadaşlar, şimdi bu ders videosunda, bazı gerçekçi örneklerin
yardımıyla koşul değişkeni ve sessiz erişim kullanımını uygulayalım.
Şimdi bu örnekte, tüketici üçlüsü olarak adlandırılan birinci anlaşmamızı
ve üretici tehdidi olarak adlandırılan ikinci anlaşmamızı görebilirsiniz.
Doğru.
Ve bazı veri yapılarımız var.
Bu veri yapısının hiçbir işe yaramadığını, sadece bazı veri elemanları içerdiğini ve
31 ve 32'nin bu veri yapısına erişmek için birbirleriyle yarıştığını varsayalım.
Şu anda 31 yaşındaki Sousa, tüketici olarak çalışıyor.
Bu basitçe, 381'in çarpıklıktan bir öğeyi çıkarmak ve işlemek istediği anlamına gelir.
Doğru mu? Treaty two ise bir
üretici iş parçacığıdır ve bazı veriler
üretir ve bu verileri kuyruğa iter.
Doğru.
İşte bu nedenle Treaty one bu kuyruğu
tüketirken, Treaty skew'e daha fazla veri besler.
Bu nedenle, 382 üretici ipliği olarak adlandırılırken, antlaşma tüketici eğilimi olarak adlandırılır.
Artık kabileler arasında paylaşılan bir kaynak olan bir veri yapısı ipucumuz var.
Şimdi, durum yapısı üzerinde karşılıklı dışlama sağlamak için, bu veri yapısının kendisiyle
ilişkili bir sessiz nesneye sahip olması ve koşul değişkenine sahip olması gerekir.
Ayrıca, koşul değişkeni tüketici ve üretici tehditlerini senkronize etmek için
kullanılır, değil mi? Unutmayın, Murdochs nesnesi ve koşul değişkenleri
veri yapısının özellikleridir, ancak koşul değişkeninin veri yapısı yerine
bir üçlünün özelliği haline geldiği bazı küçük sapmalar vardır.
Ancak durumu basit tutmak için, sadece o koşul değişkenine gidelim ve vergilendirelim.
Her ikisi de şu anda kaynağın özellikleridir.
Bu örneği açıkladıktan sonra, 381 ve ready to board'un bu
veri yapısından bir eleman üretme ve tüketme adımlarını gözden geçireceğiz.
Q birbirini dışlayan bir şekilde.
Doğru.
Ve bunun için, tehditler bu koşul değişkenini ve muteksi kullanır mı?
Evet arkadaşlar, sorunumuz şu: 381, Q'dan bir öğeyi kaldırmaya çalışıyor.
Bu unsuru engellenmeden Q'dan başarıyla çıkarır.
Doğru mu? Elbette, 381'in Q'ya yalnızca Q
382 hakkı tarafından kullanılmadığında erişmesi gerekir.
Ancak 31 kuyruktan bir eleman çıkarmaya çalışırsa ancak kuyruk zaten boşsa,
bu durumda tüketici iş parçacığımız engellenmeli ve bir üretici iş
parçacığı olan trajedi de kuyruğa yeni bir eleman itene kadar
engellenmiş kalmalıdır, değil mi? İşte çözmeye çalıştığımız problem cümlesi budur.
Ve daha meşhur olarak, bu problem ifadesi üretici tüketici problemi olarak adlandırılır.
Dolayısıyla sorun ifadesi, 381'in kuyruktan bir öğeyi kaldırmaya çalışması ve
kuyruğun zaten boş durumda olması halinde engellenmesi gerektiği konusunda açıktır.
Doğru.
Ve tüketici iş parçacığının, üretici iş parçacığı bir
öğe üretip kuyruğa itene kadar bloke kalması beklenir.
Doğru.
Şimdi bu mantığı uygulamak için vergilerden önceki koşul değişkeninin
ve yüklemin nasıl bir araya getirilebileceğini adım adım görelim.
Şimdi, yüklem karşılaştığınız yeni bir terimdir.
Yüklemin tam olarak ne olduğunu açıklayacaktım.
Öncelikle tüketici iş parçacığı ile başlayalım, tamam mı? Tüketici iş
parçacığının yapması gereken ilk şey, bir kuyruk olan paylaşılan kaynak
üzerinde bir kilit elde etmektir, değil mi? Unutmayın, Kuyruk paylaşılan
bir kaynaktır ve her iki iş parçacığı da bu
paylaşılan kaynağa erişim talep ederken karşılıklı dışlama kuralına uymalıdır.
Bu nedenle, tüketici işleminin bu kuyruk üzerinde herhangi bir işlem
gerçekleştirebilmesi için öncelikle SKU üzerinde bir kilit elde etmesi gerekir.
Şimdi, çift olduğunu varsayarsak.
Bu kuyruk üzerinde kilit elde edebilir.
31'in yapacağı bir sonraki şey, bu kuyruktan bir öğe tüketmektir.
Doğru.
Ve 31, bu kuyruktaki öğeyi yalnızca kuyruk boş olmadığında tüketebilmelidir.
Bu da basitçe, kuyruk boşsa tüketici tehdidinin engelleneceği anlamına gelir.
Doğru.
Böylece, ikinci adımda tüketici tehdidinin kaynağın durumunu, yani
kuyruğun boş olup olmadığını test ettiğini görebilirsiniz.
Dolayısıyla, bu musluk numarasını yalnızca iki olarak gerçekleştirmek, kaynağın bu durumunu kontrol etmek anlamına gelir.
İş parçacığı tarafından kaynağın durumunu kontrol etmek için
kullanılan koşul, teknik olarak yüklem olarak adlandırılır.
Yani bu koşula yüklem denir.
Yani bu sadece ticari senkronizasyon dünyasında kullanılan teknik bir terimdir ve
yüklem, iş parçacığının kaynağın durumunu test ettiği koşulu temsil eder.
Dolayısıyla, yalnızca adım numarasını gerçekleştirmek için tüketici ticaretini satın almak gerekir.
Adım S1 bir gereklidir, yani muteksin kilitlenmesi gereklidir.
Şimdi bu muteksin neden gerekli olduğunu anlıyorsunuz.
Doğru.
Böylece ticaret, tehdit kaynağın durumunu kontrol ederken
kaynağın durumunu özel olarak kontrol edebilir.
Sürecin başka hiçbir iş parçacığı kaynağın durumunu değiştirmemelidir.
İşte bu nedenle muteks kilitleme gereklidir.
Bir numaralı adım ve yüklem, iş parçacığına beklemesi gerekip gerekmediğini söyleyen bir koşuldur.
Doğru.
Bu örnekte, iki numaralı adım koşulu test eder
ve teknik olarak bu koşula yüklem denir.
Şimdi, tüketicinin ipucunu boş olarak bulduğunu varsayarsak, yani tüketici
ticaretinin engellenmesi gereken tüketiciyi tüketecek hiçbir şeyi yoktur.
Üçüncü adımda, tüketici tehdidini engellemek için ihtiyaç duyduğumuz
API be tehdit koşulunu çağırmamızın nedeni de budur.
Problem ifadesinin bir parçası olarak, üretici tehdidi bu öğeyi
boş kuyruğa itene kadar tüketicimizin bloke kalmaya çalışmasını istiyoruz.
Yani burada, bekleme koşulu doğruysa, yani kuyruk boşsa.
Tüketici haklarımız üçüncü adımda kendisini bir koşul değişkeni olarak bloke ediyor,
değil mi? Yani şimdi üç numaralı adımda, tüketici engellenmiş durumda.
Doğru.
Bu da tüketici ticaretinin artık beklediği anlamına geliyor.
Üretici bir öğe üretmeye ve onu kuyruğa itmeye çalıştı.
Bu da basitçe yapımcı Ted'in artık resmin içine gireceği anlamına geliyor.
Şimdi, yapımcı Ted'in kuyruğa bir öğe itmesi gerekiyor.
Bu, üretici iş parçacığının paylaşılan kaynak üzerinde doğru bir işlem gerçekleştirdiği anlamına gelir.
Doğru.
Yani bu basitçe, üretici tehdidinin de paylaşılan kaynak işaretine
karşılıklı olarak özel bir erişime ihtiyacı olduğu anlamına gelir.
Ve bu nedenle, üretici iş parçacığı muteksin kilitlenmesiyle başlar, değil
mi? Unutmayın, tüketici tehdidi blok durumundadır, şampiyon numarası üçtür.
Ve bu özel muteksin perde arkasında kilidinin açıldığını zaten biliyoruz.
Ve bu muteksin kilidi açıldığı için, polis atad artık
altıncı adımda bu muteks üzerindeki kilidi ele geçirebilir.
Şimdi, bir üretici iş parçacığı Q dolu değilse bunu test
edecektir, değil mi? Yani, bu yedi numaralı adımdır, o zaman
üretici işlem bir öğe üretebilir ve onu kuyruğa itebilir.
Dolayısıyla bu özel eylem, paylaşılan bir kaynak üzerinde gerçekleştirilen doğru bir işlemi temsil eder.
Değil mi? Başka bir deyişle, bu kritik bölümdür ve
üretici iş parçacığı öğeyi başarılı bir şekilde kuyruğa ittikten
sonra, Üretici A'nın tüketici iş parçacığına sinyal göndererek
tüketicinin bir iş parçacığı almaya çalıştığını bildirdiğini görebilirsiniz.
Kuyruğa bir öğe yerleştirdim.
İnfazınıza devam edebilirsiniz, değil mi? Yani bıçaklanma sayısından
sonra, ısı bir tehdit üreterek infaz edildiğinden.
Bu koşul değişkenine bir sinyal gönderilecektir, doğru, bu nedenle iş parçacığı kontrollerinin
üreticisi olan 32, kaynaklar altı numaralı adımda ayrıcalık sözü verirken adım numarasının
yedi olduğunu alır ve bu yeni öğeyi üretir ve kuyruğa işaret eder.
Ardından üretici Ted, sekiz numaralı adımda hapsolmuş tüketiciye bir sinyal
gönderir ve dokuz numaralı adımda üretici üçlüsü muteksin kilidini açar.
Değil mi? Yani bu
API kilidini açmak.
Sekiz numaralı adımdan hemen sonra ve dokuz numaralı adımdan önce,
tüketicinin blog durumundan yürütmeye hazır durumuna geçmeyi denediğini unutmayın.
Ancak dört numaralı adımı yürütecek olan tüketici, yalnızca üretici iş
parçacığı dokuz numaralı adım olan muteksin kilidini başarıyla açtığında, ancak
S9 numaralı adımdan sonra tüketici etiketi gerçekten yürütmeye başlar.
Dolayısıyla, S4 adımında, tüketici iş parçacığı yürütmeye devam eder etmez, bu muteks
üzerindeki kilit işletim sistemi tarafından dahili olarak tüketici iş parçacığına verilir.
Doğru.
Ve bu nedenle, yalnızca bu SKU üzerinde işlem yapabilen tüketici.
Yani, artık SKU'dan bir öğe tüketebilir.
Yani dördüncü adım, uyandırıldığında çalışan tüketicinin bulunduğu kritik bölümdür.
Değil mi? Ve son olarak, tüketici
işaretten bir öğe tüketirken işi
bittiğinde, tüketici muteksin kilidini açabilir.
Değil mi? Yani adım numarasında, X5 bunu
yaptığında paylaşılan verilerin kilidini açıkça açar.
Tüm bu hikayede, kritik bölümü temsil eden adımlar nelerdir diye soracak olursam,
basitçe tanımdan yola çıkarak kritik bölüm, paylaşılan kaynağa eriştiğimiz kod parçasıdır.
Yani üretici tarafındaki bu belirli kod bölgesi kritik bölümdür ve
tüketici tarafındaki bu belirli kod bölgesi de kritik bölümdür, değil
mi? Tüm bu hikayeyi analiz ederseniz, tüketici ve üreticinin
zamanın herhangi bir noktasında karşılıklı dışlama ilkesine uyduğunu göreceksiniz.
Değil mi?
Yani rehidrasyon.
Bir kez daha, bu muteksin rolü, rakip iş parçacıklarının paylaşılan kaynağa karşılıklı
olarak özel bir erişime sahip olmalarına izin vermektir, oysa bu koşul değişkeninin
rolü, kaynak hakkı için rekabet eden iş parçacıkları arasında koordinasyona izin vermektir.
Bu koşul değişkeni sayesinde tüketici üçlüsü kendini bloke edebildi ve
üretici üçlüsü koşul değişkenine sinyal gönderebildi, değil mi? Ayrıca, şimdi
S1'den S9'a kadar olan otobüs musluk numarasını tamamladık ve
eksik damga numarasını iki, dört ve yedi olarak kapattık.
Doğru.
Şu an itibariyle, iş parçacığı senkronizasyonunun en zor kısmı olan
koşul değişkeni ve Maraxus ile çalışıyorsunuz, değil mi? Daha fazla
vergi ve koşul değişkeninin nasıl kullanılacağına dair net bir resim
elde ettiğinizde, Monitor, Sema Force vb. gibi alternatif senkronizasyon
için kullanılan daha sofistike ve karmaşık tertile yapılarını uygulayabileceksiniz.
Şimdi bu kod parçasında, bir sonraki
derste tartışacağımız bir iyileştirme kapsamımız var.