std::thread'in yok edicisi, iç durumunu kontrol eder. Eğer thread joinable kalırsa - yani, henüz join edilmiş veya detach edilmemiş aktif bir yürütme thread'ini temsil ediyorsa - yok edici std::terminate çağrısını tetikler ve programın muhtemel bir rogue thread ile devam etmesini engeller. Bu tasarım, açık yaşam döngüsü yönetimini zorunlu kılar, ancak istisna güvenliği ve erken dönüş yolları açısından önemli bir sorumluluk oluşturur.
std::jthread, C++20'de tanıtılarak, bu riski ortadan kaldırır ve işbirlikçi iptali ile senkronizasyonu kendi RAII tasarımında kapsüller. Yok edicisi önce iptal sinyalini bir iç std::stop_source aracılığıyla gönderir, ardından automatik olarak join() çağrısını gerçekleştirir ve thread'in yürütmesi tamamlanana kadar engeller. Bu, nesne yok edilmeden önce thread'in zarif bir şekilde sonlanmasını sağlarken, manuel müdahale olmadan kazara sonlanma olasılığını ortadan kaldırır.
// Tehlikeli: std::thread void risky_task() { std::thread t([]{ /* arka plan çalışması */ }); if (config_error) return; // std::terminate() burada çağrılır! t.join(); } // Güvenli: std::jthread void safe_task() { std::jthread t([](std::stop_token st) { while (!st.stop_requested()) { /* çalışma */ } }); if (config_error) return; // Güvenli: yok edici durmayı talep eder ve katılır }
Gelen alıntıları işlemek için bir piyasa veri besleyici thread'i başlatan yüksek frekanslı bir ticaret uygulamasını düşünün. Başlatma sırasında eğer ağ yapılandırması geçersiz çıkarsa, fonksiyon erken döner ve std::thread nesnesi join() çağrılmadan önce yok edilir. Bu senaryo, kaynak edinmenin thread oluşturulduktan sonra başarısız olabileceği asenkron I/O bağlı uygulamalarda sıkça meydana gelir ve üretim ortamlarında hemen çöküşlere yol açar.
Düşünülen bir yaklaşım, thread'i manuel bir try-catch bloğu içine alarak, her dönüş yolu ve istisna işleyicisinden önce join() çağrısının yapılmasını sağlamaktı. Açık olmasına rağmen, bu kırılgan oldu; yeni çıkış noktaları eklemek veya yeniden yapılandırmak, sıklıkla katılma mantığının göz ardı edilmesine neden olan gerilemeler oluşturdu ve hata kurtarma sırasında ara sıra std::terminate çağrılarına yol açtı.
Değerlendirilen başka bir çözüm, thread referansını saklayan ve yok edicisinde katılan özel bir ScopeGuard sınıfıydı. İyileştirilmiş güvenlik mantığını kapsüllese de, kütüphanede zaten standartlaşmış olan işlevselliği tekrarladı ve birden fazla modül arasında tekrarlayan kodları sürdürmeyi gerektirdi, bu da teknik borç ve inceleme yükünü artırdı.
Ekip nihayetinde std::jthread'ı benimseyerek C++20'ye geçiş yaptı. std::thread'i değiştirerek, yok edici otomatik olarak std::stop_token aracılığıyla iptali sinyal veriyor ve manuel senkronizasyon blokları olmadan thread'in tamamlanmasını bekliyordu. Bu, istisnalar veya erken dönüşler sırasında temizliğin sağlanmasını yükünden kurtardı ve hem daha güvenli hem de daha sürdürülebilir bir kod tabanı oluşturdu.
Neden bir std::thread üzerinde join() iki kez çağırmak tanımsız bir davranışa yol açar ve std::jthread bunu nasıl programatik olarak önler?
Bir std::thread nesnesi, geçerliliği olan bir yürütme thread'ine ait bir handle’a sahip olup olmadığını takip eder. join() çağrıldığında, thread non-joinable hale gelir, ancak standart, sonraki çağrıların bu durumu güvenli bir şekilde kontrol etmesini zorunlu kılmaz. join()'in yeniden çağrılması, thread'in joinable olması gerektiği ön koşulunu ihlal eder ve genellikle çöküşler, deadlock'lar veya kaynak sızıntıları olarak ortaya çıkan tanımsız davranışa yol açar.
std::jthread, iç durum izleme aracılığıyla join()'in idempotent olmasını sağlar. Yok edici, yalnızca thread joinable ise join() çağrısını yapar ve sonraki açık çağrılar güvenli bir şekilde hiçbir şey yapmaz; bu durum akıllı gösterici resetleme işlemlerinin davranışıyla eşleştirilerek yanlışlıkla çift katılma hatalarını önler.
Nasıl std::jthread'in std::stop_token işbirlikçi iptali gerçekleştirir ve bu, asenkron thread kesme ilkelerinden neden üstündür?
std::jthread, her thread'i bir std::stop_source ile eşler ve thread'in giriş işlevine bir std::stop_token gönderir. İşçi, döngüsünden temiz bir şekilde çıkmak için periyodik olarak stop_requested()'u kontrol eder ve bu sayede invariants korunur ve mutex'ler serbest bırakılır. Bu, std::thread ile kesmenin, yürütmeyi ortadan kaldırmak için platforma özgü çağrılara (pthread_cancel veya TerminateThread gibi) ihtiyaç duymasıyla keskin bir şekilde karşılaştırılır; bu, yürütmeyi orta talimat da durdurur ve paylaşılan kaynakları bozulmuş veya kilitli bir durumda bırakabilir.
Bir std::jthread başka bir nesneye taşındığında iptal sinyali ne olur ve çalışan thread transferi gözlemler mi?
std::jthread taşındığında, kaynak nesne, temel thread handle'ının ve std::stop_source'un sahipliğini terk eder ve boş ve non-joinable hale gelir. Hedef nesne thread'in kontrolünü devralır. Kritik olarak, işçi fonksiyonuna geçirilen std::stop_token, std::stop_source tarafından yönetilen stop_state'e referans verdiği için geçerliliğini korur; bu, herhangi bir token veya kaynak onu referans gösterdiği sürece sürer. Thread, yeni jthread nesnesinin sahipliğinde çalışmaya devam eder ve yeni handle aracılığıyla iptal talepleri orijinal işçiye sorunsuz bir şekilde ulaşır.