Evet arkadaşlar, şimdi bir önceki ders videosundaki Dharma projemizi uyguladık
ve ayrıca daha önce radyonun biraz karasal olduğunu söylemiştik.
Şimdi çift grup kütüphanemizi Stibbe sürecimizle nasıl
entegre edebileceğimizi ve sorunu nasıl çözebileceğimizi tartışacağız.
Bu nedenle, bir kez daha nemlendirmek için, kullanıcı girişi dinleyici izlerinin
yanı sıra dinleyici iş parçacıklarına geri dönen dinleyici musluklarımız var.
Paket dinleyici iş parçacıkları paketi işlev paketi sürecine besler.
Tamam.
Ve kullanıcı girişi dinleyici izleri Clia verilerini Clia işleyici işlevine besler.
Yani bu mevcut tasarımdır ve bu fonksiyonların her biri daha sonra
yönlendirme tablosunu güncellemek için fonksiyonu çağırır, bu stajyerler adım adım
işlemle sahip olunan yönlendirme tablosu doodle yapısını güncellemek için bakarlar.
Yani bu, dinleyicinin çalıları işlediği bir numaralı adımdır.
İşlevler için etkinlikler vardır.
Öyleyse buna ikinci adımda bir numaralı adım diyelim.
Bu işlevler kova işlemi yapar ve Clia Handler verilerini
ABD'ye muhtemelen yönlendirme tablosu API'sine iter ve üçüncü adımda
sonunda yuvarlak tabloyu güncelleyen Yönlendirme Tablosu API'sini alması istenir.
Tamam.
Ve dediğim gibi, yuvarlak masa aynı anda birden fazla iş
parçacığı bağlamında güncellendiğinden, tahmin sürecimiz iş parçacığı güvensiz bir süreçtir.
Tamam.
Şimdi hangi çözümü uygulayacağımızın önemli noktalarını tartışalım.
Bu yüzden bile akışkanımızı SGP süreciyle entegre edecektik ve denemek için
bile sadece tek iş parçacıklı işlemci talimatlarını yürüten yürütme birimi olmalıdır.
Tamam.
Dolayısıyla STV sürecinin her yarışması, olay döngüsü
izi ve Kuzey İzi bağlamında yürütülmelidir.
Bu nedenle, bunu kova listesinin UI iş parçacığında izlenmediği, doğrudan
yerleştirilmiş uygulamayı yürütmek yerine hesaplamalarını olay döngüsüne gönderdiği şeklinde okumayalım.
Dolayısıyla, bu noktada, dinleyici iş parçacıklarına ve kullanıcı giriş iş parçacıklarına geri
dönen bu dinleyici iş parçacıklarının her biri, hesaplamalarını doğrudan bu API'ye yönlendirme
tablosunu güncellemek için gönderir ve bu da gerçek veri yapısını günceller.
Tamam.
Yani aradığımız şey, bu dinleyici iş parçacıklarının her birinin
uygulama mantığını doğrudan yürütmek ve uygulama veri yapısını güncellemek
yerine kendi hesaplamalarını olay döngüsü iş parçacığına göndermesi gerektiğidir.
Sonuç olarak, olay döngüsü dinleyici trance adına tüm hesaplamaları tetikler ve bu nedenle
Astrobee süreci bir kez daha mantıksal olarak tek iş parçacıklı sürece indirgenir.
Tamam.
Mantıksal olarak diyorum çünkü teknik olarak STV süreci dinleyiciyi uzun süre transa geçirdi.
Yani teknik olarak SDP sürecimiz çok iş parçacıklı bir süreçtir, ancak mantıksal
olarak olay döngülerini kullanarak bunu tek iş parçacıklı bir sürece indirgememiz gerekir.
Ve bu durumda, dinleyici transının tek bir amacı olacaktır ve bu amaç sadece harici
olayları dinlemektir ve bloklama adımı ve dinleyici transının eşzamanlılık sağlamak gibi bir amacı yoktur.
Tamam.
Denemelerin eşzamanlılık sağlamak için icat edildiğini zaten biliyorsunuz, ancak bu
durumda dinleyici iş parçacıklarının tek amacı harici olayları dinlemektir.
Ve bundan sonra, yapacağız.
Zamanlayıcı ile nasıl yürüyebileceğimizi göreceğiz diyor, Peki, harici bir zamanı veya kütüphaneyi işliyorsak
geri kalanıyla entegre edeceğiz ve zamanlayıcıların asenkron programlamada nasıl bir rol oynadığını göreceğiz.
Dolayısıyla bu, bir sonraki başlıkta ele alacağımız bir konudur.
Yani daha ileri gitmiyorum.
Şimdi uygulayacağımız çözüm stratejisini tartışalım.
Bu yüzden yeni bir API uygulayacağız, buna SGP güncelleme yönlendirme tablosu diyeceğiz.
Çözüm olarak yapacağımız şey, dinleyicinin rakiplerinden bazılarını iplikten geçirmesiydi.
İlgili işleyicilerini yapın, işleyiciler, process ve Clia işleyicisine geri dönen işlevler anlamına gelir.
Yani bu bir numaralı personeldi, daha sonra bu işleyici işlevlerine
bir adımda, hesaplamalarını LSD işlevine, SDP güncelleme yönlendirme tablosuna gönderecekti.
Şimdi bu fonksiyonun olay döngüsüne bazı hesaplamaları girme sorumluluğu vardır.
Tamam.
Yani bu üçüncü adımdır ve yarışma kuş gribine teslim edildiğinde,
kuş gribi tehdidinin sinyali verilecek ve hatta şehirdeki dünya seyahati,
dördüncü adım olan API SDP güncelleme yuvarlak masa toplantısını çağıracaktır.
Yönlendirme tablosu API'si ile ilgili olarak, beş numaralı adım olan
uygulamaların gerçek veri yapısını eninde sonunda güncelleyeceğimizi zaten biliyoruz.
Yani uygulayacağımız tüm döngü bu.
Daha önce, bu işleyici işlevler SDP güncelleme yönlendirme tablosu işlevini doğrudan çağırıyordu,
ancak şimdi, SDP güncelleme yönlendirme tablosu API'sini doğrudan güncellemek yerine, bu işleyici
işlevler bir API SDP güncelleme yönlendirme tablosu kullanarak hesaplamalarını olay Lou'ya göndereceklerdir.
Tamam.
Ve bu hesaplama olay döngüsüne gönderildikten sonra, diyelim ki C bir,
C iki, vb. hesaplamalar, bu hesaplamalar olay Lou tarafından bir API
SDP güncelleme yönlendirme tablosunu çağırarak ateşlenecek ve sonunda yönlendirme yapısını güncelleyecektir.
Yani bunu görebilirsiniz.
Çeşitli dinleyici iş parçacıklarından toplanan
olaylar, olayın öncesindeki göreve, Lou.
Ve sonra Lou bile bu kombinasyonları seri olarak teker teker ateşler.
Sonuç olarak, US TB sürecinin veri yapıları seri olarak güncellenir.
Yani eşzamanlı olarak değil teker teker ve sadece
bakılan bağlamında güncellenir ve başka hiçbir şey denenmez.
Şimdi yapacağımız bir sonraki çalışmada bu beş adımı teker teker uygulayalım.
Bunlar, bir sonraki VİDEO dersinde uygulayacağımız beş adımdır.
Şimdilik, bu adımları uygulayabilir ve çözümü kendi başınıza uygulamaya çalışabilirsiniz.
Ama her neyse, bir sonraki dersimizde size bu beş adımı nasıl uygulayacağınızı göstereceğim.
Nihai hedefimiz, API SDP güncelleme yönlendirme tablosunun dinleyici iş
parçacıkları yerine Olay Döngüsü sekmesi tarafından çağrılmasını sağlamak olacaktır.
Bu bizim nihai hedefimiz.
Bir sonraki ders olan VİDEO'da bunu nasıl başaracağımızı görelim.