**std::promise**'in istisna nesnelerini thread sınırları arasında ilişkili **std::future**'a iletme mekanizmasını ve bunun neden paylaşılan durum içinde istisna türünün tür silme gerektirdiğini tanımlayın.

Sorunun Cevabı

Sorunun geçmişi.

C++11'de std::future ve std::promise aracı, threadler arasında asenkron sonuç iletimini resmileştirmek için geldi. Önceki yaklaşımlar, istisna işleme neredeyse imkansız hale getiren, manuel senkronizasyona dayanan ad-hoc paylaşımlı bellek kullanıyordu. Standartizasyon komitesi, bir işçi threadinde atılan herhangi bir istisna türünü yakalayacak bir mekanizma gerektiriyordu ve bu istisnayı depolama noktasında statik türünü bilmeden bekleyen threadde güvenilir bir şekilde yeniden oluşturabilmeliydi.

Sorun.

İstisna nesneleri polimorfik ve varsayılan olarak yığın üzerinde tahsis edilir, ancak bunlar ürettikleri std::promise'in kapsamını aşmak zorundadır. std::future yalnızca sonuç türü üzerinde şablonlandığı için, paylaşılan durumda tipli bir istisna üyesi bulunamaz. Ayrıca, tüketici threadinin yapımcı threadinden daha uzun sürmesi gerektiğinden, istisnanın yığın üzerindeki depolamada kalıcı olması için yığın-aşırı tahsisat ile sürdürülmesi gerekir.

Çözüm.

Standart, std::promise'in std::current_exception() kullanarak istisnaları yakalaması gerektiğini belirtir, bu da istisnayı yığına kopyalayarak tür silme işlemi gerçekleştirir ve tür silinmiş bir referans tutucu saklar. Paylaşılan durum (bir referans sayımlı kontrol bloğu) bu std::exception_ptr'yi saklar ve std::future::get() ile istisnayı tespit etmeye ve std::rethrow_exception() kullanarak yeniden fırlatmaya olanak tanır.

std::promise<int> prom;
auto fut = prom.get_future();

std::thread([&prom]{
    try {
        throw std::runtime_error("İşçi başarısız oldu");
    } catch(...) {
        prom.set_exception(std::current_exception());
    }
}).detach();

try {
    int val = fut.get(); // runtime_error'ı yeniden fırlatır
} catch(const std::exception& e) {
    // Taşınan istisnayı işler
}

Hayat durumu

Kapsam.

Dağıtık bir işlem çerçevesi, işçi threadlerinin GPUOutOfMemory veya CorruptInputData istisnaları nedeniyle başarısız olabileceği görüntü segmentasyon görevlerini işlemesini gerektirdi. Ana thread, bu belirli istisnaları alarak yedek CPU işleme veya veri yeniden iletimini tetiklemek için ihtiyaç duyuyordu.

Sorun tanımı.

Başlangıçta std::exception_ptr'i manuel olarak kullanan ilk denemeler, ana threadin hata kuyruğuyla hala referans edilen istisnaların yok olması gibi yaşam süresi hataları yaşadı. Geliştiriciler, birliktelikte nesne dilimlenmesi veya polimorfik depolama sırasında nesne dilimleri olmadan, tek bir sonuç kabında farklı türdeki istisnaları depolamakta da zorluk yaşadılar.

Çözüm 1: Tipli istisna kuyrukları.

Ekip, her istisna türü için ayrı kuyruklar sürdürmeyi düşündü. Bu, tür güvenliği sağladı, ancak ortak kuyrukta tür silme için std::any gerektirdi ve önemli bir yük ve karmaşıklık ekledi. Ayrıca, tüketici threadinde try-catch blokları ile doğal olarak istisnaları yakalama yeteneğini de kırdı.

Çözüm 2: Sanal istisna tutucu.

Bir abstract ExceptionBase sınıfı uyguladılar ve türetilmiş sınıfları std::unique_ptr<ExceptionBase> içinde depoladılar. Bu, polimorfik depolamayı mümkün kıldı, ancak threadler arasında paylaşılan sahipligi sürdürmek için manuel klonlama mantığı gerektirdi ve yeniden fırlatma sırasında sanal yönlendirme yükü ekledi. Özel referans sayma hata yapma eğilimindeydi ve kendisi de istisna güvenli olma bakımından zordu.

Seçilen çözüm ve neden.

Ekip, std::packaged_task ve std::future'ı benimsedi, bu içsel olarak std::promise/std::exception_ptr mekanizmasını kullanır. Bu, istisna yakalama ve paylaşılan durum ömrünü otomatik olarak standart kütüphane tarafından işlenmesini sağladığı için özel tür silme kodunu ortadan kaldırdı. Seçim, sıfır bakım istisna güvenliği gereksinimi ve özel temel sınıflar olmadan standart istisna işleme desenlerini destekleme gereksinimi tarafından yönlendirildi.

Sonuç.

Sistem, bellek sızıntısı olmaksızın, özel istisna türlerini thread sınırları arasında başarılı bir şekilde iletti, hatta agresif thread havuz yeniden boyutlandırması sırasında. Ana thread, bilinmeyen hatalar için varsayılan olarak std::exception'a geçerken, özellikle GPUOutOfMemory'yi yakalayabildi ve hata işleme mantığı ile thread eşleştirme mantığı arasında temiz bir ayrım sağladı.

Adayların genellikle kaçırdığı şeyler

Soru: Neden std::current_exception() istisna nesnesini mevcut istisnanın üzerine bir işaretçi saklamak yerine kopyalar?

Cevap.

Bir catch bloğundaki istisna nesnesi, genellikle yığın sökme sırasında çalışma zamanı tarafından oluşturulan geçici bir kopyadır. Ham bir işaretçi saklamak, bir catch bloğunun dışına çıkıldığında ve yığın çerçevesi yok olduğunda iptal edilen bir referans yaratır. İstisnayı yığına kopyalayarak, std::current_exception() nesnenin atılan threadin yığınından bağımsız olarak kalıcı olmasını sağlar. Bu kopyalama işlemi ayrıca tür silme mekanizmasını mümkün kılar ve std::exception_ptr'nin nesneyi tür silinmiş bir silici aracılığıyla yönetmesine olanak tanırken, sonradan tam orijinal türü yeniden fırlatabilme yeteneğini de sürdürür.

Soru: std::promise set_value() ile set_exception() arasında yarış durumlarını nasıl önler?

Cevap.

Paylaşılan durum, vaadin gerçekleştirildiğini takip eden atomik bir durum bayrağı içerir. set_value() veya set_exception() çağrıldığında, uygulama durumu "tatmin edilmemiş"ten "hazır"a geçmek için atomik bir karşılaştırma-ve-değiştirme işlemi gerçekleştirir. Eğer durum halihazırda hazırsa, işlem std::future_error ile promise_already_satisfied fırlatır. Bu atomik geçiş, hazır durumu gözlemleyen tüketici threadinin tam olarak inşa edilmiş bir değer veya istisna görmesini sağlar ve üretici ile tüketici arasındaki eşzamanlı erişim sırasında kısmi okumaların veya yazımların önlenmesini sağlar.

Soru: Neden std::exception_ptr, onu oluşturan std::promise ve std::future'den daha uzun yaşayabilir?

Cevap.

std::exception_ptr, istisna nesnesinin üzerine, std::future/std::promise paylaşılan durumundan bağımsız olarak, müdahaleci referans sayımını kullanır. Bu tasarım, istisna işleme kodunun, asenkron işleme tamamlandıktan ve ilişkili future/promise nesneleri yok edildikten sonra, hataları uzun süreli kayıtlara veya hata işleyicilere saklamasına olanak tanır. Referans sayma, istisna nesnesinin yalnızca onu referans alan son std::exception_ptr yok edildiğinde yok edilmesini garantiler, gecikmeli hata raporlama veya birden fazla asenkron işlem arasında istisna toplama gibi kullanım durumlarını destekler.