Evet, çocuklar, şimdi Taimur'un nasıl yürüdüğünü, yani işletim
sisteminin zamanlayıcı kavramını nasıl uyguladığını anlamaya çalışalım.
Dolayısıyla Zamanlayıcı, ayrı bir iş parçacığı veya tamamen ayrı
bir süreç olabilen ayrı bir kod akışı bağlamında yürür.
Öyleyse bunu aşağıdaki diyagramın yardımıyla anlamaya çalışalım.
Makinenizde çalışan bir B uygulaması yazdığınızı varsayalım.
Bu uygulamada, bazı argümanları kabul eden aptal bir fonksiyonunuz var.
Değil mi? Ve işlevsizlik
bir parça iş yapar.
Man, çalışan ve mantığını yürüten gerçek uygulamanızı temsil ediyor, değil mi?
Burada zamanın bir noktasında uygulamanızın yeni bir zamanlayıcı başlattığını varsayalım.
Değil mi? Diyelim ki new time a
launch, uygulamanızın yeni bir zamanlayıcı başlatmak
için kullandığı varsayımsal bir API olsun.
Doğru mu? Şimdi, uygulamanızın bir zamanlayıcı başlattığını
unutmayın çünkü uygulamanız zamanlayıcı sona erdiğinde yürümek
için benzersiz bir şey yapmak istiyor.
Değil mi? Zamanlayıcının sona ermesi
sonucunda yapılan iş birimi, bu
aptal fonksiyon tarafından temsil edilir.
Doğru.
Dolayısıyla, ne zaman bir zamanlayıcı oluştursak, zorlamamız
gereken zorunlu argümanlardan biri fonksiyon işaretçisidir.
Bu işlev işaretçisi, zamanlayıcınızın süresi dolduğunda çalıştırılacak bir işlevi temsil eder.
Değil mi? Ve eğer bir
fonksiyonu çağırıyorsanız, bu fonksiyona bazı
argümanlar eklemeniz gerektiği açıktır.
Yani her zamanlayıcı için en az iki şeyi duraklatmanız gerekir.
Birincisi, zamanlayıcı ateşlendiğinde yürüteceği iş birimidir.
Bu iş birimi bu aptal fonksiyon tarafından temsil edilir.
İkinci argüman ise bu aptal fonksiyona argüman olarak ayrıştırılacak olan argümandır.
Değil mi? Dolayısıyla, bu API çağrılır çağrılmaz, süreciniz
sonraki kod satırlarını yürütmeye devam edecek, işletim
sisteminiz ise yeni bir iş parçacığı oluşturacaktır.
Bu kod satırını doğru eklediğinizde yeni bir iş parçacığı D1 şeklinde ayrı bir kod akışı oluşturacaktır.
Doğru.
Dolayısıyla bu blok, patent süreci tarafından oluşturulan yeni bir D1 iş parçacığını temsil eder.
Şimdi, bu API'nin son kullanma süresi beş saniyeye eşit olan bir işlem oluşturduğunu varsayalım.
B Süreci bu ipliği çatallar çatallamaz.
Değil mi? Bir zamanlayıcı oluşturmak için, bu
iş parçacığı çalışmayacak ve bloke kalacaktır.
Doğru mu? İşletim sistemi bu tehdidi blok halinde
tutacaktır, oysa R süreci P API'den sonra
istediğini yürütebilir, yanında yeni bir zaman dönmüştür.
İş parçacığı çatallanması bu şekilde çalışır, değil
mi? Ana süreciniz yürütme akışına devam eder.
Şimdi, bu zamanlayıcının sona erme süresi beş saniye olarak ayarlandığından.
Bu, sadece beş saniye geçtikten sonra işletim sisteminin burada
belirtilen AIG argümanıyla bir fool fonksiyonunu çağıracağı anlamına gelir.
Şu anda, aptal fonksiyon sahip olduğu mantığı yürütebilir.
Zamanlayıcının nasıl yürüdüğünü görebilirsiniz.
için işlevi, zamanlayıcı ateşlendiğinde yapmamız gereken yürüyüş birimini temsil
eder, değil mi? Dolayısıyla, işlev havuzu yalnızca API yeni
başlatma zamanının çağrılmasından sonra beş saniye geçtikten sonra tetiklenecektir.
Böylece Full zamanlayıcı bağlamında yürütülmesini tamamladığında, denenen zamanlayıcı kapatılır.
Zamanlayıcının kapatıldığını söylediğimde, zamanlayıcı iş parçacığının çekirdek
veya işletim sistemi tarafından öldürüldüğü anlamına gelir.
Dolayısıyla, bu işlev yürütülmesini tamamlayıp geri döner dönmez,
tragedy one zamanlayıcısı çekirdek tarafından otomatik olarak öldürülür.
İşletim sistemimiz, çünkü zamanlayıcı tarafından yapılması gereken iş birimi tamamlanmıştır.
İşlem olan uygulama ücreti, yalnızca tam bir işlevin sonunda
bir zamanlayıcı tarafından işgal edilen tüm kaynakları serbest bırakmalıdır.
Şu anda, bu argümanı hazırlamak için uygulamanızın belirli veri yapılarını
doğru şekilde günlüğe kaydetmiş olması ve bu öğrenci yapılarının bu
zamanlayıcı işlevine aptal bir argüman olarak ayrıştırılmış olması mümkün olabilir.
Doğru.
Yani bu tam fonksiyonun sonunda bu veri yapılarını beslemek sizin sorumluluğunuzda, değil
mi? Zamanlayıcı işlevi yürüyüşünü tamamlamadan hemen önce, tüm kaynakları serbest bırakmalıdır.
Merak etmeyin, tüm bu mantığı uygulayacaktık ve bunu
nasıl yapacağınızı bir örnek yardımıyla size göstereceğim.
Yani teknik terimle aptal işlevine zamanlayıcı geri çağrısı denir.
Zamanlayıcıların işletim sistemi tarafından nasıl uygulandığına ilişkin burada
tartıştığımız mekanikler tüm zamanlayıcı türleri için geçerlidir.
Yani, bir kısa zamanlayıcı, periyodik zamanlayıcı veya üstel geri çekilme zamanlayıcısı.
Bir kısa zamanlayıcı olması durumunda, işlev yürütülmesini tamamen
tamamladığında, albay veya işletim sistemi 381 hakkını öldürür.
Periyodik zamanlayıcı durumunda ise, işlev tam olarak yürütülmesini
tamamladığında, işletim sistemi 381'i tekrar blok durumuna geçirir.
Doğru.
Ve bir oyundan sonra, beş saniye geçti.
Sonra tekrar fonksiyon çağrılır ve bu döngü sonsuza kadar tekrar eder.
Ve zamanlayıcının üstel geri dönüşünün fonksiyon olması durumunda, Fu yürütülmesini tamamlamıştır.
İşletim sistemi yine zamanlayıcı 381'i bloga doğru belirtmek için koydu.
Ancak şimdi beş saniye beklemek yerine 10 saniye bekleyeceğiz.
Doğru.
Ve yalnızca 10 saniye geçtikten sonra, zamanlayıcı geri çağrısı
yürütülmesini bitirdiğinde yalnızca zamanlayıcı geri çağrısı tekrar çağrılır.
İşletim sistemi T1 zamanlayıcısını tekrar engellenmiş duruma
getirecek ve bu kez süre bekleyecektir.
T 20 saniyeye eşittir.
Değil mi? Yani her seferinde bekleme zamanlayıcısı
önceki bekleme süresinin iki katı olacaktır.
Dolayısıyla, kısa, periyodik ve üstel zaman geri
dönüşünü uygulamak için temellerin farklı olmadığını görebilirsiniz.