İçsel zayıf işaretleyicinin hangi belirli başlatma durumu `std::enable_shared_from_this` sınıfından miras alan bir sınıfın yapıcı işlemi sırasında `std::shared_from_this()` çağrıldığında `std::bad_weak_ptr` fırlatmasına neden olur?

Soruya Cevap

std::enable_shared_from_this, tipik olarak weak_this olarak adlandırılan özel değişken mutable bir std::weak_ptr<T> üyesini kapsayan bir karışım temel sınıfıdır. Türetilmiş nesnenin inşası sırasında, bu içsel weak_ptr varsayılan yapılandırmaya tabi tutulur ve boş (süresi dolmuş) bir durumda kalır. Kritik mimari ayrıntı, bu içsel işaretleyicinin kontrol bloğunu referans alacak şekilde başlatılmasının yalnızca yönetilen nesnenin yapıcı işlemi tamamlandıktan sonra std::shared_ptr yapıcı işlemi içerisinde gerçekleşmesidir. Bu nedenle, yapıcı gövdesi sırasında shared_from_this() çağrıldığında boş bir weak_ptr üzerinde lock() çağrısı yapılmaya çalışılır. C++17 itibarıyla bu durumda bir std::bad_weak_ptr istisnasının fırlatılması zorunludur (veya daha eski standartlarda tanımsız bir davranış), çünkü yeni referansların sağlanabilmesi için gerekli olan paylaşımlı sahiplik altyapısı henüz kurulmamıştır.

Hayattan Bir Durum

Kontekst:

Yüksek frekanslı ticaret platformu, borsa ile sürekli TCP bağlantılarını yönetmek için bir MarketDataHandler sınıfı uyguladı. Bu sınıfın, asenkron soket okuma/yazma işlemleri sırasında hayatta kalmasını garanti altına almak amacıyla std::enable_shared_from_this<MarketDataHandler> sınıfından miras aldı. Yapıcı, bağlantı parametrelerini kabul etti ve hemen bir asenkron okuma işlemini başlatarak shared_from_this()'i tamamlayıcı işlev olarak Boost.Asio olay döngüsüne geçirdi.

Sorun:

Entegrasyon testleri sırasında, uygulama bağlantı kurulduğunda hemen yakalanmamış std::bad_weak_ptr istisnalarıyla çökerek süreci sonlandırdı. Geliştirme ekibi, temel sınıf std::enable_shared_from_this alt nesnesinin, türetilmiş sınıfın yapıcı gövdesi çalışmadan önce oluşturulduğunu varsaydıkları için, içsel izleme mekanizmasının hemen kullanılabilir olacağını düşünüyordu. Ancak, nesne inşası ile std::shared_ptr sarmalayıcısının tamamlanması arasında geçen zaman aralığını göz ardı ettiler; bu, içsel weak_ptr'in fabrika ifadesi tamamlanana kadar başlatılmış olmaktan uzak durmasına neden oldu.

Düşünülen Alternatif Çözümler:

post_construct() ile İki Aşamalı Başlatma:

Sınıfı yeniden yapılandırarak asenkron başlatma mantığını yapıcıdan ayırıp ayrı bir post_construct() genel yöntemine taşıyabiliriz. Çağıran ilk olarak std::make_shared<MarketDataHandler> kullanarak bir std::shared_ptr<MarketDataHandler> oluşturacak ve ardından sonucu döndürmeden önce post_construct()'i hemen çağıracaktır.

• Artılar: Uygulaması basit; mevcut sınıf hiyerarşisinde minimal yapısal değişiklikler gerektirir.
• Eksiler: Harici bir başlatma gereksinimi getirerek RAII ilkelerini ihlal eder; nesne var ama tam işlevsel değil olan "zombi" durumu oluşturur; çağıranlar post_construct()'i çağırmayı unutabilir, bu da işleyicilerin verileri işleme sürecine girmediği ince hatalara yol açar.

Harici Yaşam Süresi Garantileri ile Ham İşaretçi:

Ham this işaretçisini asenkron G/Ç sistemine geçin ve std::shared_ptr anahtarları kullanarak aktif bağlantıların ayrı bir genel kaydını sürdürebilir, her geri çağırma yürütmesinde kayıt üyeliğini kontrol edebilirsiniz.

• Artılar: Yapıcı sırasında kaydı geçerli hale getirir, shared_from_this() gerektirmez.
• Eksiler: Manuel yaşam süresi yönetimi akıllı işaretçilerin amaçlarını bozar; genel kayıt için karmaşık senkronizasyon gereksinimleri getirir; hızlı bağlantı döngüsü sırasında geri çağırmalar kayıt temizleme mantığını aşarsa kullanımdan sonraki hatalara son derece duyarlıdır.

Özel Yapıcı ile Statik Fabrika Metodu:

Tüm yapıcıları özel yapmak ve bir std::shared_ptr<MarketDataHandler> döndüren genel bir statik create() yöntemi sağlamak. İçerisinde create(), öncelikle nesneyi std::make_shared ile başlatacak ve ardından sonucu döndermeden önce asenkron işlemleri başlatacaktır.

• Artılar: Hiçbir MarketDataHandler nesnesinin bir std::shared_ptr tarafından sahiplenilmeden var olamayacağını zorunlu kılar; başlatmanın atomik olmasını garanti eder; yalnızca paylaşımlı sahiplik için tasarlanmış nesnelerin tehlikeli yığın tahsisini önler.
• Eksiler: Fabrikanın arkadaş olarak ilan edilmediği takdirde özel yapıcılarla std::make_shared kullanımını engeller; biraz daha ayrıntılı bir sözdizimi gerektirir (MarketDataHandler::create() ile std::make_shared<MarketDataHandler>() arasında).

Seçilen Çözüm:

Statik Fabrika Deseni, shared_from_this()'in sahiplenilmeyen bir nesne üzerinde çağrılma olasılığını ortadan kaldırdığı için seçildi. Yapım işleminin create() yöntemine kısıtlanması sayesinde, std::shared_ptr kontrol bloğunun her zaman tam olarak inşa edilmesi ve içsel weak_ptr'in herhangi bir yöntem, yeni referanslar sağlamadan önce başlatılmış olması sağlandı.

Sonuç:

Yeniden yapılandırma, tüm başlangıç çökmelerini ortadan kaldırdı. Kod tabanı, ağ katmanında tutarlı bir şekilde uygulanan asenkron nesne oluşturma için sağlam bir desen benimsendi. Kod inceleme yönergeleri fabrikadan sonra çağrılan yöntemler dışında herhangi bir shared_from_this() çağrısını yasaklayacak şekilde güncellendi ve yaşam süresine bağlı hata oranlarını önemli ölçüde azalttı.

Adayların Genellikle Gözden Kaçırdığı Noktalar

Soru: shared_from_this() referans sayısını artırır mı ve kontrol bloğuyla nasıl etkileşime girer?

Cevap:

shared_from_this() yeni bir kontrol bloğu oluşturmaz. Bunun yerine, std::enable_shared_from_this temel sınıfında depolanan içsel değişken mutable std::weak_ptr<T> üyesine erişir ve üzerinde lock() çağrısı yapar. Bu işlem atomik olarak kontrol bloğunun hala var olup olmadığını kontrol eder ve eğer öyleyse, mevcut kontrol bloğuyla ilişkili güçlü referans sayısını artırarak yeni bir std::shared_ptr örneği döndürür. Eğer nesne zaten yok olmuşsa (süresi dolmuş zayıf işaretçi), lock() boş bir std::shared_ptr döndürür. Adaylar genellikle shared_from_this()'in basitçe bazı içsel shared_ptr'nin bir kopyasını döndürdüğünü düşünürler; oysa ki aslında zayıf bir referansı güçlü birine yükseltme işlevi görmesi, "çift sahiplik" senaryolarından kaçınmak için kritik öneme sahiptir; bu da iki bağımsız std::shared_ptr örneğinin aynı nesneyi farklı referans sayılarıyla takip etmesi durumudur.

Soru: Bir sınıf birden fazla kez std::enable_shared_from_this<T>'den miras alabilir mi veya bir dörtgen hiyerarşisinde birden fazla yol üzerinden mi?

Cevap:

Bir sınıf, aynı T için std::enable_shared_from_this<T> sınıfından doğrudan birden fazla kez miras alamaz çünkü bu, belirsiz temel sınıf alt nesneleri yaratır. Ancak Derived sınıfı yalnızca std::enable_shared_from_this<Derived>'den miras almalıdır, bir üst sınıfın sürümünden değil. Adayların gözden kaçırdığı kritik detay, sanal mirastır: Eğer Base std::enable_shared_from_this<Base>'den miras alıyorsa ve Derived de Base'den miras alıyorsa, Derived içinden bir Base işaretçisinde shared_from_this() çağrılması doğru çalışır çünkü içsel weak_ptr en türetilmiş nesneye işaret edecek şekilde başlatılmıştır. Ancak, Derived aynı zamanda std::enable_shared_from_this<Derived>'den de herkese açık şekilde miras alırsa, bu iki ayrı weak_ptr üyesi oluşturur, bu da hangi üyenin başlatılacağı konusunda kafa karışıklığına yol açar. Standart, std::shared_ptr yapıcılarının başlatmaları sırasında özellikle std::enable_shared_from_this özelikleri arayacağını belirtir; bağımsız weak_ptr üyelerinin bulunması yalnızca birinin (genellikle ilk oluşturulan std::shared_ptr ile ilişkilendirilenin) başlatılmasıyla sonuçlanır ve bu da diğerlerinin boş kalmasına neden olarak sonraki shared_from_this() çağrılarının başarısız olmasına yol açar.

Soru: Yapıcı sırasında std::make_shared ile std::shared_ptr<T>(new T) arasındaki fark neden shared_from_this() için güvenlik açısından önemsizdir?

Cevap:

Her iki tahsis stratejisi de nihayetinde std::enable_shared_from_this temel sınıfını şablon metaprogramlama aracılığıyla tespit eden bir std::shared_ptr yapıcı çağrısını tetikler. İçsel weak_ptr'in başlatılması, yalnızca std::shared_ptr yapıcı mantığı içinde gerçekleşir; bu, new T sırasında veya make_shared'in dahili nesne inşası aşamasında gerçekleşmez. Özellikle, make_shared belleği ayırır, T nesnesini oluşturur (bu esnada weak_ptr boş kalır) ve ancak sonrasında std::shared_ptr yapıcısı weak_ptr'i yeni oluşturulan kontrol bloğuna işaret edecek şekilde başlatır. Adaylar genellikle make_shared'in belki de nesneyi daha önce "hazırlayacağını" varsayıyor, ancak standart, hangi fabrika işlevinin kullanıldığına bakılmaksızın, yapıcı gövdesinden shared_from_this() çağrısının güvensiz olduğu garantisini sağlar çünkü weak_ptr ataması yalnızca T yapıcısı tamamlandıktan sonra gerçekleşir.