Şimdi dinleyici tehditlerinin ne olduğunu ve bunlara neden ihtiyaç duyduğumuzu tartışalım.
Yavaş yavaş asıl sorunumuza, yani kusurların serileştirilmesi ifadesine doğru yaklaşıyoruz.
Bu nedenle, bir uygulamanın sürekli olarak harici olayları dinlemesi gereken yaygın bir senaryodur.
Bu harici olaylar herhangi bir zamanda gelebilir ve uygulamanın bu olayları işlemesi gerekir.
Uygulama bu harici olayları dinlemek için tehditleri kullanabilir.
Pekala, diyelim ki SDP olarak adlandırılan örnek bir sürecimiz var.
Burada, sürecimizin tek iş parçacıklı bir süreç olduğunu vurgulamak için SDP adını seçiyorum.
Bu işlemin örtüşen bir özelliğe sahip olduğu anlamına gelir ve basitçe
bu uygulamanın tasarım gereği tek iş parçacıklı olması gerektiği anlamına gelir.
Dolayısıyla bu çok güçlü bir varsayımdır ve zamanın herhangi bir noktasında,
bu süreç mantığını çoklu tehditler bağlamında yürütmeye çalışırsak, bu basitçe
varsayımımızı ihlal ettiğimiz ve tam bir başarısızlık olduğu anlamına gelir.
Tamam.
Diyelim ki bir STB sürecimiz var ve bu tek iş parçacıklı
bir süreç ve bu sürecin belirli rutinleri ve işlevleri var.
Tamam.
Şimdi bu işlevlerin her birinin ne yaptığını açıklayayım.
Şimdi, sürecimizin bir ağ soketini dinlemesi
gerektiğini varsayalım, böylece paket dış ağdan
geldiğinde, sürecimiz bu paketi işleyebilmelidir.
Bu yüzden sürecimizin bir ağ soketini dinlemesi gerekir.
Tamam.
Sürecimizin yaptığı şey, yeni üçlüye odaklanmak ve bu
güvenin bir ağ soketini dinleme sorumluluğuna sahip olmasıdır.
Yani böyle bir üçüncüye paket dinleyici iş parçacığı denir.
Dinleyici iş parçacığı kavramını bir önceki ders radyosunda zaten açıklamıştım,
bu nedenle bu basitçe bu paket dinleyici iş parçacığının engellendiği
ve şimdi paketin bir sokete gelmesini beklediği anlamına gelir.
Ve paket gelir gelmez, paket dinleyici iş parçacığı olan bu iş parçacığı,
paket işleme işlevine bir çağrı yaparak paketi ortalama uygulama koduna enjekte eder.
Tamam.
Ve Argumento, bu fonksiyon az önce gelen B paketidir.
Böylece bu rutin paket sürecinin SDP sürecimize ait bir rutin olduğunu görebilirsiniz.
Ve bu paket işlem rutini, paket geldiğinde
paket dinleyici iş parçacığı bağlamında yürütülür.
Tamam.
Bir SDP'nin ağdan gelen belirli paketleri bu kadar basit bir şekilde işlemesi bir gerekliliktir.
Benzer şekilde, sürecimizin işletim sisteminden gelen belirli
olayları dinlemek için haber olacağını varsayalım.
Şu ana kadar işlemimizin tekrar Kernel Even Listener Thread adında yeni bir parça oluşturması gerekiyor.
Merak etmeyin, size bir sürecin nasıl bir grup dinleyici iş parçacığı
oluşturabileceğini ve harici olayları dinleyebileceğini göstereceğim bir demo program oluşturacağız.
Tamam.
Dolayısıyla, çekirdekten veya temel işletim sisteminden gelen herhangi
bir olay SDP sürecinin ana mantığına enjekte edilecektir.
Neden rutin bir
olay? Pekala.
Böylece Colonel Evens işlevi bu çekirdek olay dinleyicisi iş parçacığı bağlamında yürütülür.
Aynı şey STP sürecimizle etkileşime geçmek isteyen kullanıcı için de geçerlidir.
Sürecimiz SDP tarafından oluşturulan başka bir iş parçacığı daha vardır ve bu iş parçacığı kullanıcı
girdisi dinleyici iş parçacığı olarak adlandırılır ve bu iş parçacığı sürekli olarak kullanıcıdan girdi bekler.
Bir kullanıcı sürece bazı bilgiler girebilir.
Neden bazıları seelye ya da
bazıları UI? Önemli değil.
Böylece herhangi bir girdi gelir gelmez, Clia işleyici
işlevi kullanıcı girdisi dinleyici iş parçacığı bağlamında yürütülecektir.
Tamam.
Ve son olarak, sistemde STP sürecimize bazı
veriler gönderen başka bir süreç olabilir.
Neden süreç iletişiminde olan IPC? Sürecimiz,
kanıtları tekrar dinlememiz gerekip gerekmediğini sordu.
Bazı harici süreçlerden gelebilecek tüm veriler tek ve herhangi bir zamanda olabilir.
Ve bunun için, sürecimizin süreç iletişim iş parçacığı adı
verilen yeni bir dinleyici iş parçacığı oluşturması gerekir.
Tamam.
Ve süreç iletişim iş parçacığı tarafından herhangi bir veri tespit edilir edilmez, süreç iletişim
iş parçacığımız bir işlev IPC sürecini çağırarak bu verileri uygulama ESDP kaydına iter.
IPC süreci işlevini bu süreç iletişim iş parçacığı bağlamında yürüteceğiz, böylece bir
iş parçacığı kullanarak bir sürecin aynı anda tüm olayları dinleyebileceğini görebilirsiniz.
Ve hatta geldiğinde ve bu olaylar işlendiğinde,
ancak bu olaylar dinleyici tehditleri bağlamında işlenir.
Ve son olarak, bazı iç olaylar olabilir.
Örneğin, sizin süreciniz.
SDP, zamanlayıcı iş parçacığı adında bir iş parçacığı oluşturdu.
Ve diyelim ki 10 saniye sonra ya da diyelim ki keyfi sayıda
saniye sonra, zamanlayıcı izleri zamanlayıcı olay işlevini çağırarak uygulama SDP'sine yeni bir
hesaplama enjekte eder, böylece zamanlayıcı bile işlevi zaman tehdidi bağlamında yapıcıda yürütülür.
Bu yüzden endişelenmenize gerek yok, bir tür uygulama olacak şekilde bir örnek
uygulayacağız ve size çeşitli dinleyici iş parçacıklarını nasıl başlatacağınızı göstereceğim ve ardından
bu dinleyici iş parçacıklarının ilgili olayları STP sürecimize nasıl itebileceğini göstereceğim.
Şimdi burada varsayımdaki en büyük sorunumuzun SDP sürecinin
tek iş parçacıklı bir süreç olması olduğunu görebilirsiniz.
Ancak şimdi, çeşitli dinleyici denemeleri ve zamanlayıcı iş parçacıkları başlattıktan sonra, uygulamamız SDP,
temel tasarımına ve mimarisine aykırı olan çok iş parçacıklı tasarıma doğru ilerleme eğilimindedir.
Bu işlevlerin packet process, IPC process, yield, handler kernel, hatta
evenson timer bile kendi dinleyici iş parçacıklarının bağlamında yürütüleceğini görebilirsiniz.
Yani bu, Tippi'nin şu anda zorla sahip olduğu gibi, bu sürecin çok iş parçacıklı hale geldiği
ve geliştiricinin olayları dinlemek için tehditleri dinlemeye başlamak zorunda olduğu için hiçbir seçenek görmediği anlamına gelir.
Sahip olduğu tek yol bu.
Aynı zamanda, tahmin süreci örtüşen veri yapıları özelliğine sahip
olduğundan, tipu sürecini tek iş parçacıklı olarak sürdürmek istiyor.
Dolayısıyla, harici olayları dinlemek ve aynı zamanda süreci tek
bir iş parçacığı olarak sürdürmek için iki gereksinim vardır.
Bu iki gereklilik birbiriyle çelişiyor gibi görünmektedir.
b işleminin bazı D veri yapılarını koruduğunu düşünün.
Tamam.
Ve paket dinleyici iş parçacığının, paket işlem rutininin çağrıldığı ve
bu Pockett işlem rutini nedeniyle bazı Paket B aldığını varsayalım.
Diyelim ki b veri yapısını güncellemeye çalışıyor, bu durumda D
veri yapısı paket dinleyici iş parçacığı bağlamında güncelleniyor demektir.
Aynı zamanda, P1 sürecinin IPC süreci işlevinin dahil
olduğu bazı veriler gönderdiğini ve bu işlevin
de aynı veri yapısını güncellemeye çalıştığını varsayalım.
Yani şimdi bu güncelleme bu süreç iletişim dizisi bağlamında yapılıyor.
Yani iki farklı iş parçacığı şimdi aynı veri yapısını güncellemeye çalışıyor
ve bu nedenle kilitlemeyi dağıtmanız gereken üçüncü bir senkronizasyona ihtiyaç var.
Yani bir kez daha, p sürecimizin tek iş parçacıklı
bir süreç olmayan bir ESDP olduğu yayılımına karşı çıkıyoruz.
STP sürecimizin kaynak kodu içinde herhangi bir kilitleme
tüm iş parçacığı senkronizasyon tekniğini kullanmamamız gerekiyor.
Bunu yaptığınız anda, bu varsayımı elde edeceksiniz.
Artık sorun ifadesi açık olduğuna göre, süreç harici
olayları dinlemek isterken, aynı zamanda sürecin dahili uygulama
mantığını tek iş parçacıklı olarak sürdürmek istemesi gerekir.
Peki bu nasıl başarılabilir, çözüm olay döngüsünden geliyor
ve bundan sonra tartışacağımız şey de bu.
Dolayısıyla sorun ifadesi açıktır.
Şimdi bu sorunu çözmek için mavinin bile nasıl kullanılabileceğini tartışacağız.