Swift 5.5 ve yapılandırılmış eşzamanlılık uygulandığında, geliştiriciler, isteğe bağlı kimlikler, kimlik doğrulama belirteçleri veya günlüğe kaydetme bağlamları gibi bağlamsal meta verilerin, işlev imzalarını kirletmeden derin asenkron çağrı yığınları boyunca yayılmasını sağlamakta zorluklarla karşılaştılar. Geleneksel yaklaşımlar, hem eşzamanlılık tehlikeleri hem de API sürtünmeleri yaratan global değişkenlere veya açık manuel geçişe dayanıyordu. TaskLocal, yapılandırılmış eşzamanlılık hiyerarşisini göz önünde bulundurarak örtük, sözdizimsel kapsamlı durumu sağlamak için bir çözüm olarak ortaya çıktı.
Temel zorluk, Task hiyerarşilerinin ebeveyn-çocuk ilişkilerini otomatik olarak takip eden, iş parçacığı güvenli, izole bir bağlam depolama alanını sürdürmektir. Diğer dillerde bulunan iş parçacığı yerel depolamadan farklı olarak, Swift'in eşzamanlılık modeli, görevlerin iş parçacıkları arasında göç ettiği iş çalma iş parçacığı havuzlarını içerir ve bu da iş parçacığı yerel depolamasını geçersiz kılar. Ayrıca, kaplamalarda açık yakalama, her asenkron sınırdan yanlış geçiş gerektirir ve yapılandırılmış eşzamanlılığın soyutlamasını kırar.
Swift, görevin dahili bağlamında depolanan kopyala-yaz bağlaması yığını kullanarak görev yerel depolaması uygular. Her Task örneği, TaskLocal bağlamalarının bağlı olduğu bir bağlı liste (yığın) işaretçisi tutar. Bir görev bir çocuk görev yarattığında, çocuk mevcut yığının başına referans alır ve tüm ebeveyn bağlamalarını devralır. Bir değer, .withValue() kullanılarak bağlandığında, mevcut görevin yığına anahtar-değer çifti içeren yeni bir yığın düğümü itilir, bu da o anahtar için önceki değeri gölgeler. Bu yapı, aramaların mevcut görevden ataları boyunca geçmesini sağlar, O(n) arama sunarken, n bağlama derinliğidir ve çocuk görev yaratımları için O(1) mirası korur.
enum TraceContext { @TaskLocal static var id: String? } await TraceContext.$id.withValue("trace-123") { await performDatabaseQuery() }
Swift ile yazılmış bir mikro hizmet arka ucu için dağıtılmış bir izleme sistemi düşünün. Her gelen HTTP isteği, hizmet sınırları boyunca gözlemlenebilirliği korumak için veritabanı sorguları, önbellek aramaları ve çıkış ağ çağrıları arasında yayılması gereken benzersiz bir izleme kimliği üretir.
Problem tanımı
Kod tabanı, birden fazla katmanda yüzlerce asenkron işlev içermektedir: denetleyiciler, hizmetler, depolar ve ağ istemcileri. İzleme kimliğini her işlev imzası aracılığıyla açık bir parametre olarak geçmek, yüzlerce yöntem imzasında değişiklik yapmayı gerektirir, kapsüllemeyi kırar ve bakım kabusları yaratır. Global bir değişken kullanmak, sunucunun binlerce eşzamanlı isteği işlemesi gerektiği için başarısız olur; bir global, isteklerin birbirlerinin izleme kimliklerini üzerlerine yazmasına neden olarak yarış koşulları yaratır.
Düşünülen Farklı Çözümler
Düşünülen bir yaklaşım, tek bir bağlam nesnesi olarak geçirilen bir bağımlılık enjeksiyon konteyneri kullanmaktır. Bu, parametre sayısını azaltır ancak yine de her işlev imzasını değiştirmeyi gerektirir ve konteyner türüne sıkı bağlılık yaratır. Ayrıca, kişiselleştirilmiş bağlam parametrelerini kabul etmeyen üçüncü taraf kütüphane sınırları boyunca otomatik olarak yayılma sağlamaz, entegrasyonu acı verici hale getirir.
Başka bir seçenek, her asenkron işlemin açık bir şekilde izleme kimliğini kapladığı manuel Görev değeri geçişi idi. Bu, doğruluğu garanti eder ancak aşırı tekrara yol açar; geliştiricilerin her asenkron sınırda kimliği kaplamayı ve iletmeyi hatırlamaları gerekir. Bağlamı yaymayı unutan insan hatası riski, bu çözümü kırılgan ve büyük bir ekip içinde sürdürülemez hale getirir.
Seçilen çözüm ve neden
Ekip, izleme kimliğini tutmak için TaskLocal depolamasını seçti. Bu yaklaşım, işlev imzalarını değiştirme gereğini ortadan kaldırırken izleme kimliğinin otomatik olarak yapılandırılmış eşzamanlılık ağacını takip etmesini garanti etti. Bir istek yöneticisi, paralel veritabanı sorguları için çocuk görevler oluşturduğunda, her bir çocuk otomatik olarak ebeveynin izleme kimliğini devralır ve açık yakalamaya gerek kalmaz. Bu çözüm, Swift'in eşzamanlılık güvenliği garantilerine saygı gösterir ve minimum kod değişiklikleri gerektirir; sadece giriş noktası kimliği bağlar ve aşağıdaki tüketiciler bunu örtük olarak okur.
Sonuç
Uygulama, API yüzey değişikliklerini %95 oranında azaltarak 200'den fazla işlev imzasından izleme kimliği parametrelerini kaldırdı. Sistem, eşzamanlı istekler arasında izleme izolasyonunu doğru bir şekilde korudu ve global duruma sahip olsaydı meydana gelebilecek çapraz kontaminasyon sorunlarını önledi. Bellek profilleme, TaskLocal'ın bağlı değerlerin yaşam döngüsünü verimli bir şekilde yönettiğini ve görevler tamamlandığında referansları otomatik olarak serbest bıraktığını, manuel temizlik kodu gerektirmediğini ortaya koydu.
Görevden ayrılmış görevler ile yapılandırılmış çocuk görevler oluşturulurken TaskLocal nasıl davranır?
Adaylar genelde tüm görevlerin görev yerel değerleri eşit bir şekilde devraldığını varsayarlar. Ancak, Task.detached açıkça ayrışma zincirini izole olma amacıyla kırar. Ayrılmış bir görev oluşturduğunuzda, boş bir görev yerel depolama alır; bu, hassas bağlamın kasıtlı olarak izole çalışmalara sızmasını önler. Buna karşılık, Task { } ve TaskGroup oluşturulan görevler ebeveynin bağlama yığınını devralır. Bu ayrım, gizlilik sınırları ve kaynak temizleme bağlamları için kritik öneme sahiptir; burada örtük durumun taşıdığından emin olmak istersiniz.
TaskLocal'da güçlü referansların bağlanmasının bellek yönetimi üzerindeki etkileri nelerdir?
Geliştiriciler sıklıkla TaskLocal'ın herhangi bir bağlı değere güçlü bir referans tuttuğunu, görevin yürütülme süresi boyunca boyunca unutur. Eğer büyük bir nesne grafiğini veya self'i yakalayan bir kaplamayı bağlarsanız, bu bellek görevin tamamlanana kadar ayrılmış kalır, değer artık erişilmese bile. Bu, beklenmedik bellek yüklerine veya tutma döngülerine neden olabilir; çünkü bağlanan değer kendisi göreve veya bağlamına geri referanslar tutuyorsa. Zayıf referanslardan farklı olarak, görev-yerel depolama, değer başka yerlerde gerekli olmadığı zaman otomatik olarak boşaltmaz.
TaskLocal değerleri aynı görev kapsamı içinde yeniden bağlanabilir mi ve bu durum eşzamanlı çocuk görevler üzerinde nasıl bir etki yapar?
Görev yerel değerlerin, görevin süresi boyunca değişmez olduğunu düşünmek yaygın bir yanlış anlamadır. Gerçekte, withValue çağrısı, yığına yeni bir bağlama iter ve önceki değeri gölgeler. Bir yeniden bağlı çocuk görevler, yeni değeri görür, ancak kuruluş zamanlarından sonra oluşturulan mevcut eşzamanlı çocuk görevler, oluşturuldukları zamandaki değeri tutar. Bu, her çocuğun, oluşturulma anına dayanan görev-lokalleri tutma tutumunun bir anlık görüntü anlamını yaratır ve bu, daha sonraki anne mutasyonlarının zaten çalışan çocukların yürütme bağlamını beklenmedik bir şekilde değiştirmesini sağlar.