Hani bazen bir kod yazarsın, her şey kusursuz çalışıyor sanırsın ya, işte tam da öyle bir durumdaydım. Async/await mekanizmasıyla haşır neşir olurken, sanki her şey yolunda gidiyor gibiydi. Bir yandan veri çekiyorum, bir yandan kullanıcı arayüzünü güncelliyorum, arada bir de arka planda bazı hesaplamalar yapılıyor. Sanki bir orkestra şefi gibi her şeyi tıkırında yönettiğimi düşünüyordum. Ne güzel değil mi? Fakat işler beklediğim gibi gitmedi maalesef.
Bir baktım ki, uygulamam bir anda dondu kaldı. Hiçbir şey yapamıyorum, ne bir butona basabiliyorum ne de bir metin kutusuna yazı yazabiliyorum. Tamamen çakıldı yani. İlk başta aklıma hemen bir ‘infinite loop’ (sonsuz döngü) geldi. Hani olur ya, bazen bir döngü koşulu yanlış olur da program kendini sonsuz bir döngüye sokar. Ama bu sefer durum farklıydı, async/await kullanıyordum ve bu mekanizma genellikle böyle kaba hataları önler diye düşünüyordum.
Neyse efendim, oturup adım adım debug etmeye başladım. Debugger’ı taktım, kodun içine girdim. Bir de ne göreyim? Kod bir yerde takılı kalmış, ama nedenini anlamak için biraz daha derinlere inmem gerekti. Kendi programım sınıfta kaldı anlayacağınız. Tam da o sırada aklıma, bu async/await’in altında yatan o karmaşık iş parçacığı (thread) yönetimi geldi. Hani derler ya, her şey yolunda giderken birden işler karışabiliyor.
İşte tam bu noktada, karşıma çıkan o meşhur ‘deadlock’ (ölü kilitlenme) kavramı çıktı. Deadlock, basitçe iki veya daha fazla iş parçacığının birbirini beklerken sonsuza dek takılı kalması durumu. Bir iş parçacığı bir kaynağı kilitler, diğer iş parçacığı o kaynağı beklerken başka bir kaynağı kilitler ve bu kilitlenen kaynaklar birbirini tutar. Sonuç? Hepsi birden beklemeye başlar ve hiçbiri ilerleyemez. Tıpkı bir kavşakta birbirinin yolunu kesen ve hiçbiri geçemeyen arabalar gibi. Ne kadar anlamsız bir durum değil mi?
Benim yaşadığım durum da tam olarak böyle bir şeydi. Async/await ile çalışırken, bazı await’ler aynı anda farklı iş parçacıklarında çalışıyordu ve bir noktada, bir iş parçacığı diğerinin bitirmesini beklerken, diğer iş parçacığı da ilkinin bitirmesini beklemeye başladı. Yani klasik bir deadlock senaryosu. İnternette biraz araştırma yaptım, çünkü bu durumun aslında çok da nadir olmadığını gördüm. Özellikle UI thread’i ile arka plan iş parçacıklarını yönetirken dikkat etmek gerekiyormuş.
Özellikle ‘ConfigureAwait(false)’ özelliğinin önemini öğrendim. Bu küçük ama etkili ayar, await edilen operasyonun orijinal bağlamına (context) geri dönmesini engelleyerek deadlock riskini azaltıyormuş. Yani, eğer arka planda yaptığınız işlem UI’ı doğrudan etkilemiyorsa, ConfigureAwait(false) kullanmak gerçekten hayat kurtarıcı olabiliyor. Tabi bu her zaman geçerli değil, bazı durumlarda UI’a geri dönmeniz gerekebilir, orada da dikkatli olmak şart.
Şimdi size basit bir örnekle göstereyim. Diyelim ki bir butona bastınız ve bu buton bir veri çekme işlemini başlatıyor. Bu işlemi async olarak yapıyoruz ama dikkat etmezsek ne olacağını görelim. İlk kod örneğinde gördüğünüz gibi, direkt await’i kullanırsak ve UI thread’i başka bir şey yapmaya çalışırsa, işte o zaman kilitlenme kaçınılmaz olabiliyor. Kendi programım sınıfta kaldı derken aslında bu durumu kastediyordum, yani o kilitlenmeyi fark edene kadar uğraşmıştım.
Bu arada, bu tür sorunlarla karşılaşmamak için genellikle şöyle bir yol izliyorum: Eğer bir işlem sadece arka planda çalışacaksa ve sonucunu hemen UI’da göstermem gerekmiyorsa, ConfigureAwait(false) kullanıyorum. Eğer UI’a bir şey dönmesi gerekiyorsa, o zaman await sonrasında Dispatcher.Invoke veya benzeri mekanizmalarla UI thread’ine geri dönüyorum. Bu sayede hem performansı olumsuz etkilemeden hem de deadlock riskini azaltmış oluyorum. İnternette bu konuda çok güzel makaleler var, mesela şurada Google’da arama yaparsanız bolca örnek bulabilirsiniz. Hatta YouTube’da da bu konuyla ilgili harika anlatımlar mevcut, bir bakmak isteyebilirsiniz.
Şimdi gelelim o ‘yanlış’ ve ‘doğru’ kod örneklerine. İlk örnekte, sadece await kullandım ve UI’ın tepkisiz kaldığı durumu göstermeye çalıştım. İkinci örnekte ise, ConfigureAwait(false) ile bu sorunu nasıl aştığımızı göreceğiz. Basit bir değişiklik ama etkisi büyük, inanılmaz!
İşte yanlış yaptığımız o kısım:
// YANLIŞ: UI'ı kilitleyebilir public async Task VeriCekAsync() { // Uzun süren bir ağ isteği veya işlem await Task.Delay(2000); // Simüle edilmiş uzun işlem return "Veri başarıyla çekildi."; }// Kullanım sırasında: // var sonuc = await VeriCekAsync(); // UI thread'i burada kilitlenebilir
Gördüğünüz gibi, Task.Delay ile uzun süren bir işlemi simüle ettim. Bu işlem sırasında UI thread’i de await’in bitmesini beklerse, işte o zaman problem başlıyor. Neyse efendim, hemen o hatayı düzeltelim.
İşte doğrusu, ConfigureAwait(false) kullanarak:
// DOĞRU: Deadlock riskini azaltır public async Task VeriCekAsync() { // Uzun süren bir ağ isteği veya işlem var sonuc = await Task.Delay(2000).ConfigureAwait(false); // UI thread'ini kilitlemez return "Veri başarıyla çekildi."; }// Kullanım sırasında: // var sonuc = await VeriCekAsync(); // UI thread'i hala responsive kalır
Aradaki farkı görüyor musunuz? Sadece bir satır ekledik ama sonuçları bambaşka. Bu arada, bu tür async/await problemlerini çözmek için bazen gerçekten de saatlerce debug yapmanız gerekebiliyor. Ben de öyle yaptım, tam 3-4 saat sürdü galiba o deadlock’u bulmak. Ama sonunda çözünce verdiği keyif bambaşka oluyor. Yani şey gibi, bir yapbozun son parçasını bulmak gibi 🙂
Sonuç olarak, async/await kullanırken dikkatli olmakta fayda var. Özellikle UI uygulamalarında, iş parçacığı yönetimine özen göstermek gerekiyor. ConfigureAwait(false) gibi basit ama etkili yöntemlerle bu tür beklenmedik sorunların önüne geçebiliyoruz. Tabi her zaman olduğu gibi, en iyi öğrenme yolu kendi deneyimlerimizden geçiyor. Bu arada, bu tarz konularla ilgili daha fazla bilgi almak isterseniz, Reddit’te de güzel tartışmalar bulabilirsiniz.
Bu yaşadığım olay bana şunu öğretti: Kod yazarken sadece çalışan değil, aynı zamanda güvenli ve stabil çalışan kodlar yazmak önemli. Hani derler ya, ‘en iyi kod en az kod’ diye, ama bu doğru değil bence. En iyi kod, hem anlaşılır, hem verimli, hem de beklenmedik durumlara karşı hazırlıklı olan kod. İşte bu yüzden debug yapmak, test etmek çok önemli. Kendimden biliyorum, bazen sadece ‘çalışıyor işte’ deyip geçiştiriyorsun ama sonra pat diye karşına çıkıyor.
Geçenlerde eşimle Bursa’da bir dağ yürüyüşüne çıkmıştık. Hava mis gibiydi, kuşlar cıvıldıyordu. Tam zirveye yaklaşmıştık ki, telefonumdan bir bildirim geldi. Meğer yazdığım bir kodda bir hata olmuş ve sunuculardan birinde küçük bir sorun yaşanmış. Yani anlayacağınız, nerede olursanız olun, kodun peşinizden gelebiliyor! Neyse ki uzaktan müdahale edebildim ama o an düşündüm, ne kadar dağılırsak dağılalım, teknik konular zihnimizin bir köşesinde hep duruyor. Ama bu kötü bir şey değil aslında, aksine, hobilerimizle işlerimizi birleştirebilmek de bir sanat.
Bu arada, bazen düşünüyorum da, bu teknolojinin ilerleyişi inanılmaz değil mi? Eskiden böyle async/await gibi kavramlar yokken, işler ne kadar daha zormuş. Şimdi çok daha karmaşık işlemleri bile daha kolay yönetebiliyoruz. Ama her yeni teknolojiyle birlikte yeni sorunlar da ortaya çıkıyor. İşte bu da bizim gibi geliştiricilerin işi, bu sorunları çözmek, daha iyiye ulaşmak. Umarım bu anlattıklarım size de faydalı olmuştur. Herkese bol şans ve hatasız kodlar!