Task Kullanımında Doğru Bakış Açısını Yakalamak
Bu yazı dizisinde içerikte yazıyı uzun tutmadan küçük ipuçlarından bahsedeceğim. Sayfa içine eklediğim link ile konunun detaylı incelemesine de ulaşabilir olacaksınız. Böylece hem ipucunu yakalamak isteyen okurlarımız hemde konuyu detaylıca incelemek isteyen okurlarımızın daha efektif faydalanabileceğini düşünüyorum.
Bu makalemizde askenron işlemlerde Task yönetimi konusuna deyineceğim.Son zamanlarda sıklıkla karşılaştığım performans problemlerinin olduğu her yerde ilk akla gelen fikir iş parçacığını Task içerisine alınıp asenkron işletilmesi yönünde. Doğru uygulandığında mantıklı olduğuna ben de katılıyorum fakat çoğu zaman sadece avantajlı yönden bakıp “Dar boğazı açalım” başlığında nitelendiriliyor. Peki sadece bu bakış açısı ile kod yazmak iş akışımızı etkiliyor olabilir mi ? Bu konuda bir yazı yazma gereksinimide tam olarak buradan çıktı. Refactoring yaparken gördüğüm Task kullanımları sadece işi yapmak üzerine Task da yönetilen işin geri bildirimi, son durumu , hata yönetimi gibi konulara ne kadar yer veriliyor ?
Eskiden Thread yönetimini göze almak maliyetliydi. Bence bu maliyet beraberinde kontrollü, denetimi yüksek ve geri bildirimli kod akışları ortaya çıkarıyordu.
2010 yılında .Net Framework 4.0 ile birlikte Task sınıfı tanıtıldı. Üstelik LINQ gücünü de kullanarak iş parçacıklarımızı farklı Task’lar üzerinde rahatça çalıştırabilir hale geldi. Peki işlerin bu denli kolaylaşması yazılımcılar nezlinde asenkron arkaplan kullanımında dezavantajlı durumların göz ardı edilmesine neden olmuş olabilir mi ?
Bu yazımızın Trick noktası Task kullanımına ihtiyaç duyulan kod bloklarında dikkat etmemiz gereken bakış açıları
- Task’lar Asenkron olarak çalışır, bu nedenle işini ne zaman bitireceği belli değildir. Kod yazarken bu durum göz önüne alınmalıdır
- Asenkron olarak işletilen Task akışı Main Thread akışındaki değerlere etki etmemelidir. Aksi durumlarda tutarsız veriler elde edilebilir.
- Task içersinde yönetilen iş main thread üzerindeki kodu etkileyecekse ,Task işleminin sonucu Main Thread’de bekletilmelidir. Bu şekilde ana iş akışı task sonucuna göre doğru bir şekilde ilerleyebilir.
- Task içerisinde yapılan işlem Main Thread’ı etkilemese de işlem sonucu önemli olabilir.
Bu nedenle işlemin arkaplanda ki durumu veya sonucunun bilgilendirilmesi gerekebilir - Task içerisinde alınan hatalardan Main Thread sorumlu değildir, bu nedenle iş parçacığınızı doğru yönetmezseniz Main Thread akışınızın iş parçacığında alınan hatadan haberi olmayacaktır.
son maddeden gol yedim 🙂