\n Bir yaz\u0131l\u0131m geli\u015ftirme ekibi, yo\u011fun bir i\u015f y\u00fck\u00fcn\u00fc y\u00f6netmek i\u00e7in tasarlanan thread pool (i\u015f par\u00e7ac\u0131\u011f\u0131 havuzu) mekanizmas\u0131yla u\u011fra\u015f\u0131rken beklenmedik bir sorunla kar\u015f\u0131la\u015ft\u0131. Sistem, tam 64\/64 g\u00f6revi ba\u015far\u0131yla tamamlamas\u0131na ra\u011fmen, arka planda \u00e7al\u0131\u015fan bir hata ay\u0131klama arac\u0131 olan ThreadSanitizer (TSan), kodun kritik bir noktas\u0131nda, \u00f6zellikle de destructor (yok edici) fonksiyonunda bir “yar\u0131\u015f durumu” (race condition) tespit etti. Bu durum, sistemin g\u00f6r\u00fcn\u00fcrde sorunsuz \u00e7al\u0131\u015fmas\u0131na ra\u011fmen, ileride ciddi karars\u0131zl\u0131klara veya \u00e7\u00f6kemelere yol a\u00e7abilecek potansiyel bir tehlike bar\u0131nd\u0131r\u0131yordu. Bu makalede, bu vaka analizini derinlemesine inceleyecek, yar\u0131\u015f durumunun ne oldu\u011funu, neden destructor’larda ortaya \u00e7\u0131kabilece\u011fini ve TSan gibi ara\u00e7lar\u0131n bu t\u00fcr gizli hatalar\u0131 nas\u0131l ortaya \u00e7\u0131kard\u0131\u011f\u0131n\u0131 ad\u0131m ad\u0131m a\u00e7\u0131klayaca\u011f\u0131z.\n <\/p>\n
\n \u00c7oklu i\u015f par\u00e7ac\u0131\u011f\u0131 (multithreading) ortamlar\u0131nda, birden fazla i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n ayn\u0131 anda payla\u015f\u0131lan bir veri kayna\u011f\u0131na (de\u011fi\u015fken, bellek alan\u0131 vb.) eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumlarda yar\u0131\u015f durumu ortaya \u00e7\u0131kar. Bu eri\u015fimlerden en az biri yazma i\u015flemiyse, sonu\u00e7, i\u015f par\u00e7ac\u0131klar\u0131n\u0131n \u00e7al\u0131\u015fma s\u0131ras\u0131na ba\u011fl\u0131 olarak tahmin edilemez hale gelir. Basit bir \u00f6rnekle a\u00e7\u0131klamak gerekirse, iki i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n ayn\u0131 anda bir sayac\u0131 art\u0131rmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. E\u011fer saya\u00e7 10’daysa ve her iki i\u015f par\u00e7ac\u0131\u011f\u0131 da onu 11 yapmak isterse, do\u011fru s\u0131ralamada \u00e7al\u0131\u015ft\u0131klar\u0131nda sonu\u00e7 12 olmal\u0131d\u0131r. Ancak, e\u011fer her iki i\u015f par\u00e7ac\u0131\u011f\u0131 da sayac\u0131 10 olarak okuyup, art\u0131r\u0131p tekrar 11 olarak yazarsa, sonu\u00e7 11 olur. \u0130\u015fte bu, bir yar\u0131\u015f durumunun basit bir \u00f6rne\u011fidir ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn bozulmas\u0131na yol a\u00e7ar. Yar\u0131\u015f durumlar\u0131, \u00f6zellikle de e\u015fzamanl\u0131l\u0131k (concurrency) i\u00e7eren karma\u015f\u0131k sistemlerde tespit edilmesi en zor hatalardan biridir. \u00c7\u00fcnk\u00fc her zaman tekrarlanmazlar ve belirli bir zamanlama veya i\u015f par\u00e7ac\u0131\u011f\u0131 etkile\u015fimine ba\u011fl\u0131 olarak ortaya \u00e7\u0131karlar. Bu da hata ay\u0131klama s\u00fcrecini olduk\u00e7a zorla\u015ft\u0131r\u0131r. Sistemlerin kararl\u0131l\u0131\u011f\u0131, g\u00fcvenilirli\u011fi ve \u00f6ng\u00f6r\u00fclebilirli\u011fi i\u00e7in yar\u0131\u015f durumlar\u0131n\u0131n tespiti ve giderilmesi hayati \u00f6nem ta\u015f\u0131r. \u00d6zellikle sunucu uygulamalar\u0131, y\u00fcksek trafikli web siteleri veya performans\u0131n kritik oldu\u011fu g\u00f6m\u00fcl\u00fc sistemler gibi alanlarda bu t\u00fcr hatalar kabul edilemez sonu\u00e7lara yol a\u00e7abilir.\n <\/p>\n
\n Thread pool, \u00f6nceden olu\u015fturulmu\u015f ve yeniden kullan\u0131labilir bir i\u015f par\u00e7ac\u0131\u011f\u0131 k\u00fcmesidir. Yeni bir g\u00f6rev geldi\u011finde, bu g\u00f6rev havuzdaki bo\u015f bir i\u015f par\u00e7ac\u0131\u011f\u0131na atan\u0131r. G\u00f6rev tamamland\u0131\u011f\u0131nda, i\u015f par\u00e7ac\u0131\u011f\u0131 havuza geri d\u00f6ner ve ba\u015fka bir g\u00f6rev i\u00e7in haz\u0131r hale gelir. Bu yakla\u015f\u0131m\u0131n temel amac\u0131, her yeni g\u00f6rev i\u00e7in yeni bir i\u015f par\u00e7ac\u0131\u011f\u0131 olu\u015fturup yok etmenin getirdi\u011fi ek y\u00fck\u00fc (overhead) azaltmakt\u0131r. \u0130\u015f par\u00e7ac\u0131\u011f\u0131 olu\u015fturmak ve sonland\u0131rmak maliyetli i\u015flemlerdir. Thread pool, bu maliyeti en aza indirerek uygulaman\u0131n genel performans\u0131n\u0131 art\u0131r\u0131r ve kaynak kullan\u0131m\u0131n\u0131 optimize eder. Bir thread pool’un tasar\u0131m\u0131, havuzdaki i\u015f par\u00e7ac\u0131\u011f\u0131 say\u0131s\u0131, g\u00f6revlerin nas\u0131l kuyru\u011fa al\u0131naca\u011f\u0131 ve i\u015f par\u00e7ac\u0131klar\u0131n\u0131n nas\u0131l y\u00f6netilece\u011fi gibi bir\u00e7ok fakt\u00f6r\u00fc i\u00e7erir. \u00d6rne\u011fimizdeki 64\/64 g\u00f6rev tamamlama durumu, thread pool’un g\u00f6revleri etkin bir \u015fekilde da\u011f\u0131tt\u0131\u011f\u0131n\u0131 ve i\u015f par\u00e7ac\u0131klar\u0131n\u0131n i\u015flerini ba\u015far\u0131yla tamamlad\u0131\u011f\u0131n\u0131 g\u00f6stermektedir. Ancak, bu sadece d\u0131\u015far\u0131dan g\u00f6r\u00fcnen ba\u015far\u0131d\u0131r. \u0130\u00e7eride, kaynaklar\u0131n serbest b\u0131rak\u0131lmas\u0131 ve nesnelerin do\u011fru bir \u015fekilde temizlenmesi gibi daha karma\u015f\u0131k s\u00fcre\u00e7ler i\u015flemektedir. Thread pool’un verimli \u00e7al\u0131\u015fmas\u0131, sadece g\u00f6revleri zaman\u0131nda tamamlamakla kalmaz, ayn\u0131 zamanda bu g\u00f6revler s\u0131ras\u0131nda kullan\u0131lan kaynaklar\u0131n da d\u00fczg\u00fcn bir \u015fekilde y\u00f6netilmesini gerektirir.\n <\/p>\n
\n Bir nesne, kapsam\u0131ndan \u00e7\u0131kt\u0131\u011f\u0131nda veya art\u0131k kullan\u0131lmad\u0131\u011f\u0131nda, onunla ili\u015fkili kaynaklar\u0131 (bellek, dosya tan\u0131t\u0131c\u0131lar\u0131, a\u011f ba\u011flant\u0131lar\u0131 vb.) serbest b\u0131rakmak i\u00e7in destructor (yok edici) fonksiyonlar\u0131 kullan\u0131l\u0131r. C++ gibi dillerde, destructor’lar, nesnenin \u00f6mr\u00fcn\u00fcn sonuna geldi\u011finde otomatik olarak \u00e7a\u011fr\u0131l\u0131r. Bu, bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 \u00f6nlemek ve sistem kaynaklar\u0131n\u0131n verimli kullan\u0131lmas\u0131n\u0131 sa\u011flamak i\u00e7in kritik bir mekanizmad\u0131r. Bir thread pool’da, havuzdaki i\u015f par\u00e7ac\u0131klar\u0131n\u0131 temsil eden nesneler veya havuzun kendisi bir destructor’a sahip olabilir. Bu destructor, i\u015f par\u00e7ac\u0131klar\u0131n\u0131n d\u00fczg\u00fcn bir \u015fekilde sonland\u0131r\u0131lmas\u0131n\u0131, bekleyen g\u00f6revlerin temizlenmesini ve di\u011fer ilgili kaynaklar\u0131n serbest b\u0131rak\u0131lmas\u0131n\u0131 sa\u011flamal\u0131d\u0131r. E\u011fer bir destructor, payla\u015f\u0131lan bir veri yap\u0131s\u0131na eri\u015fiyorsa veya ba\u015fka i\u015f par\u00e7ac\u0131klar\u0131 taraf\u0131ndan hala kullan\u0131lmakta olan bir kayna\u011f\u0131 de\u011fi\u015ftirmeye \u00e7al\u0131\u015f\u0131yorsa, i\u015fte o zaman tehlike \u00e7anlar\u0131 \u00e7almaya ba\u015flar. \u00c7\u00fcnk\u00fc destructor \u00e7a\u011fr\u0131ld\u0131\u011f\u0131 anda, di\u011fer i\u015f par\u00e7ac\u0131klar\u0131 hala ayn\u0131 veri yap\u0131s\u0131 \u00fczerinde i\u015flem yap\u0131yor olabilir. Bu, tam da \u00f6rne\u011fimizdeki gibi bir yar\u0131\u015f durumuna yol a\u00e7abilir.\n <\/p>\n
\n ThreadSanitizer (TSan), Google taraf\u0131ndan geli\u015ftirilen, C, C++ ve Go gibi dillerde yaz\u0131lm\u0131\u015f programlardaki yar\u0131\u015f durumlar\u0131n\u0131 ve bellek hatalar\u0131n\u0131 tespit etmek i\u00e7in kullan\u0131lan g\u00fc\u00e7l\u00fc bir ara\u00e7t\u0131r. TSan, derleyiciye eklenen \u00f6zel bir ara\u00e7 tak\u0131m\u0131 (instrumentation) ile \u00e7al\u0131\u015f\u0131r. Bu ara\u00e7 tak\u0131m\u0131, kodun her yerini izler ve i\u015f par\u00e7ac\u0131klar\u0131n\u0131n bellek eri\u015fimlerini kaydeder. Bir i\u015f par\u00e7ac\u0131\u011f\u0131 bir bellek b\u00f6lgesine eri\u015fti\u011finde, TSan bu eri\u015fimi kaydeder. E\u011fer ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131 da ayn\u0131 bellek b\u00f6lgesine, ancak farkl\u0131 bir zaman diliminde, eri\u015fmeye \u00e7al\u0131\u015f\u0131rsa ve bu eri\u015fimlerden biri yazma i\u015flemiyse, TSan bir yar\u0131\u015f durumu tespit eder. TSan’\u0131n g\u00fcc\u00fc, sadece yar\u0131\u015f durumlar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda veri yar\u0131\u015flar\u0131, use-after-free (serbest b\u0131rak\u0131ld\u0131ktan sonra kullanma) gibi di\u011fer bellek hatalar\u0131n\u0131 da yakalayabilmesinden gelir. Bu ara\u00e7, program\u0131n \u00e7al\u0131\u015fma zaman\u0131 davran\u0131\u015f\u0131n\u0131 analiz ederek, geli\u015ftiricilerin normalde g\u00f6zden ka\u00e7\u0131rabilece\u011fi veya tekrarlamas\u0131 zor olan hatalar\u0131 ortaya \u00e7\u0131kar\u0131r. TSan’\u0131n dezavantaj\u0131, programa ek y\u00fck getirmesi ve \u00e7al\u0131\u015fma s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilmesidir. Bu nedenle, genellikle hata ay\u0131klama (debugging) veya test a\u015famalar\u0131nda kullan\u0131l\u0131r.\n <\/p>\n
\n Bu vakada, TSan’\u0131n 64\/64 g\u00f6revin tamamlanmas\u0131n\u0131n ard\u0131ndan destructor’da bir yar\u0131\u015f durumu tespit etmesi, olay\u0131n kritikli\u011fini vurguluyor. Bu \u015fu anlama gelir: Thread pool’daki nesneler yok edilirken (muhtemelen program sonland\u0131\u011f\u0131nda veya havuz yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda), destructor fonksiyonlar\u0131 \u00e7al\u0131\u015f\u0131yor. Ancak, bu destructor’lar, hala aktif olabilecek ba\u015fka i\u015f par\u00e7ac\u0131klar\u0131 taraf\u0131ndan eri\u015filen veya de\u011fi\u015ftirilen bir veri yap\u0131s\u0131na m\u00fcdahale etmeye \u00e7al\u0131\u015f\u0131yor. Belki de bir i\u015f par\u00e7ac\u0131\u011f\u0131 hala bir g\u00f6revi tamamlamak \u00fczereyken, destructor o g\u00f6revin sonu\u00e7lar\u0131n\u0131 veya ilgili durumu g\u00fcncellemeye \u00e7al\u0131\u015fan bir veri yap\u0131s\u0131n\u0131 temizlemeye \u00e7al\u0131\u015f\u0131yor. Bu durum, TSan’\u0131n “yar\u0131\u015f durumu” olarak i\u015faretlemesine neden oluyor. \u00d6rne\u011fin, bir g\u00f6rev bir kuyruktan veri al\u0131rken, ayn\u0131 anda ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131 (\u00f6rne\u011fin bir y\u00f6netici i\u015f par\u00e7ac\u0131\u011f\u0131) o kuyru\u011fu temizlemeye \u00e7al\u0131\u015f\u0131yor olabilir. Bu t\u00fcr bir senaryo, TSan taraf\u0131ndan tespit edilir ve geli\u015ftiricilere potansiyel bir sorunun varl\u0131\u011f\u0131n\u0131 bildirir.\n <\/p>\n
\n Bu t\u00fcr bir sorunun k\u00f6kenini anlamak i\u00e7in, thread pool’un temel i\u015fleyi\u015fini ve destructor’lar\u0131n nas\u0131l etkile\u015fime girebilece\u011fini g\u00f6steren basitle\u015ftirilmi\u015f kod \u00f6rnekleri \u00fczerinden gidelim. Ger\u00e7ek kodun karma\u015f\u0131kl\u0131\u011f\u0131na ba\u011fl\u0131 olarak senaryolar de\u011fi\u015febilir, ancak temel prensipler benzerdir.\n <\/p>\n
\n Diyelim ki bir thread pool’umuz var ve bu havuzun bir de durumu tutan bir \n Yukar\u0131daki kodda, \n TSan’\u0131n bir raporu genellikle a\u015fa\u011f\u0131daki bilgileri i\u00e7erir:<\/p>\n Bu raporu anlamak, sorunun kayna\u011f\u0131n\u0131 bulmak i\u00e7in kritik \u00f6neme sahiptir. Geli\u015ftirici, TSan’\u0131n i\u015faretledi\u011fi kod sat\u0131rlar\u0131n\u0131 incelemeli ve yar\u0131\u015f durumuna giren i\u015f par\u00e7ac\u0131klar\u0131n\u0131n hangi fonksiyonlar\u0131 \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131 anlamal\u0131d\u0131r. \u00d6rne\u011fimizdeki durumda, TSan muhtemelen \n Bu t\u00fcr yar\u0131\u015f durumlar\u0131n\u0131 \u00e7\u00f6zmek i\u00e7in birka\u00e7 farkl\u0131 strateji izlenebilir:<\/p>\n \u00d6rne\u011fimizdeki senaryoda, en etkili \u00e7\u00f6z\u00fcm muhtemelen thread pool’un destructor’\u0131nda, t\u00fcm i\u015f par\u00e7ac\u0131klar\u0131n\u0131n g\u00f6revlerini tamamlamas\u0131n\u0131 bekleyen bir mekanizma eklemektir. Bu, destructor’\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 anda \n Bu vaka analizi, g\u00f6r\u00fcn\u00fc\u015fte sorunsuz \u00e7al\u0131\u015fan sistemlerde bile gizli kalm\u0131\u015f yar\u0131\u015f durumlar\u0131n\u0131n ne kadar tehlikeli olabilece\u011fini ve ThreadSanitizer gibi ara\u00e7lar\u0131n bu t\u00fcr hatalar\u0131 ortaya \u00e7\u0131karmada ne kadar de\u011ferli oldu\u011funu g\u00f6stermektedir. 64\/64 g\u00f6revin tamamlanmas\u0131, sistemin performans a\u00e7\u0131s\u0131ndan ba\u015far\u0131l\u0131 oldu\u011funu g\u00f6sterse de, destructor’daki yar\u0131\u015f durumu, ileride ciddi karars\u0131zl\u0131klara yol a\u00e7abilecek bir “zaman bombas\u0131” olabilirdi. Geli\u015ftiricilerin, e\u015fzamanl\u0131l\u0131k ve kaynak y\u00f6netimi konular\u0131nda dikkatli olmas\u0131, TSan gibi hata ay\u0131klama ara\u00e7lar\u0131n\u0131 etkin bir \u015fekilde kullanmas\u0131 ve en iyi uygulamalar\u0131 takip etmesi, g\u00fcvenilir ve sa\u011flam yaz\u0131l\u0131mlar geli\u015ftirmek i\u00e7in hayati \u00f6nem ta\u015f\u0131maktad\u0131r. Teknolojinin ilerlemesiyle birlikte, bu t\u00fcr karma\u015f\u0131k e\u015fzamanl\u0131l\u0131k hatalar\u0131n\u0131 otomatik olarak tespit eden ve \u00e7\u00f6zen ara\u00e7lar\u0131n daha da geli\u015fmesi beklenmektedir. Ancak, temel prensipleri anlamak ve dikkatli kodlama yapmak, her zaman en iyi savunma hatt\u0131 olacakt\u0131r.\n <\/p>\n Evet, ThreadSanitizer program\u0131n \u00e7al\u0131\u015fma s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir \u00e7\u00fcnk\u00fc kodunuzu izlemek ve bellek eri\u015fimlerini kaydetmek i\u00e7in ek i\u015flemler yapar. Genellikle hata ay\u0131klama ve test a\u015famalar\u0131nda kullan\u0131l\u0131r.<\/p>\n<\/li>\n Hay\u0131r, mutexler yayg\u0131n bir \u00e7\u00f6z\u00fcm olsa da, atomik i\u015flemler, semaforlar, mesaj kuyruklar\u0131 ve dikkatli nesne ya\u015fam d\u00f6ng\u00fcs\u00fc y\u00f6netimi gibi ba\u015fka etkili y\u00f6ntemler de bulunmaktad\u0131r.<\/p>\n<\/li>\n Destructor’lar genellikle program sonland\u0131\u011f\u0131nda veya bir nesne kapsam d\u0131\u015f\u0131na \u00e7\u0131kt\u0131\u011f\u0131nda \u00e7a\u011fr\u0131l\u0131r. Bu anlarda, sistemin genel durumu karma\u015f\u0131k olabilir ve di\u011fer i\u015f par\u00e7ac\u0131klar\u0131 hala kaynaklar\u0131 kullan\u0131yor veya g\u00fcncelliyor olabilir. Bu nedenle, destructor’lar\u0131n bu de\u011fi\u015fken duruma duyarl\u0131 olmas\u0131, yar\u0131\u015f durumlar\u0131na yol a\u00e7ma potansiyelini art\u0131r\u0131r.<\/p>\n<\/li>\n TSan raporunu dikkatlice inceleyerek hangi bellek alan\u0131n\u0131n tehlikede oldu\u011funu ve hangi i\u015f par\u00e7ac\u0131klar\u0131n\u0131n eri\u015fti\u011fini belirleyin. Ard\u0131ndan, bu eri\u015fimleri senkronize etmek i\u00e7in uygun bir mekanizma (mutex, atomik i\u015flem vb.) ekleyin veya nesne ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc daha g\u00fcvenli hale getirin.<\/p>\n<\/li>\n<\/ul>\n #Teknoloji #Yaz\u0131l\u0131mGeli\u015ftirme #E\u015fzamanl\u0131l\u0131k #ThreadSanitizer #RaceCondition<\/p>\nThreadPoolState<\/code> nesnesi var. Bu ThreadPoolState<\/code> nesnesi, aktif g\u00f6rev say\u0131s\u0131, tamamlanan g\u00f6rev say\u0131s\u0131 gibi bilgileri tutabilir. \u0130\u015f par\u00e7ac\u0131klar\u0131 g\u00f6revlerini tamamlad\u0131klar\u0131nda bu durumu g\u00fcnceller.\n <\/p>\n\nclass ThreadPoolState {\npublic:\n void incrementActiveTasks() {\n \/\/ Potansiyel yar\u0131\u015f durumu noktas\u0131: Birden fazla i\u015f par\u00e7ac\u0131\u011f\u0131 ayn\u0131 anda buraya gelebilir.\n active_tasks_++;\n }\n\n void decrementActiveTasks() {\n \/\/ Potansiyel yar\u0131\u015f durumu noktas\u0131: Birden fazla i\u015f par\u00e7ac\u0131\u011f\u0131 ayn\u0131 anda buraya gelebilir.\n active_tasks_--;\n }\n\n int getActiveTasks() const {\n return active_tasks_;\n }\n\nprivate:\n std::atomicThreadPoolState<\/code> s\u0131n\u0131f\u0131ndaki active_tasks_<\/code> de\u011fi\u015fkenini std::atomic<\/code> olarak tan\u0131mlamak, basit art\u0131rma\/azaltma i\u015flemlerinde yar\u0131\u015f durumlar\u0131n\u0131 \u00f6nlemeye yard\u0131mc\u0131 olur. Ancak, daha karma\u015f\u0131k senaryolarda veya ThreadPoolState<\/code> nesnesinin kendisinin yok edilmesi s\u00f6z konusu oldu\u011funda, hala riskler mevcuttur. \u00d6zellikle ThreadPool<\/code>‘in destructor’\u0131 \u00e7al\u0131\u015ft\u0131\u011f\u0131nda ve state_<\/code> nesnesine eri\u015fti\u011finde, e\u011fer ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131 hala state_<\/code> \u00fczerinde bir i\u015flem yap\u0131yorsa (\u00f6rne\u011fin, son g\u00f6revini tamamlay\u0131p decrementActiveTasks()<\/code> \u00e7a\u011f\u0131r\u0131yorsa), TSan bunu bir yar\u0131\u015f durumu olarak i\u015faretleyecektir. Bu, destructor’\u0131n, ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n hala aktif olarak kulland\u0131\u011f\u0131 bir kayna\u011fa eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 anlam\u0131na gelir.\n <\/p>\nGeli\u015ftirici \u0130\u00e7in Ad\u0131mlar: TSan Raporunu Anlama ve Hata Ay\u0131klama<\/h2>\n
\n
ThreadPool<\/code>‘in destructor’\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 an ile ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n ThreadPoolState<\/code> nesnesine eri\u015fti\u011fi an aras\u0131ndaki \u00e7ak\u0131\u015fmay\u0131 bildirecektir. Bu durumda, geli\u015ftiricinin yapmas\u0131 gereken ilk \u015fey, destructor’\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 s\u0131rada ThreadPoolState<\/code> nesnesinin hala ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131 taraf\u0131ndan kullan\u0131lmad\u0131\u011f\u0131ndan emin olmakt\u0131r.\n <\/p>\n\u00c7\u00f6z\u00fcm Yollar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
\n
state_<\/code> nesnesine eri\u015fimini bir mutex ile koruyarak, ba\u015fka bir i\u015f par\u00e7ac\u0131\u011f\u0131 state_<\/code> \u00fczerinde i\u015flem yaparken destructor’\u0131n bekletilmesini sa\u011flayabiliriz.<\/li>\nstate_<\/code> nesnesinin hala aktif olarak kullan\u0131l\u0131yor olma ihtimalini ortadan kald\u0131r\u0131r.\n <\/p>\nSonu\u00e7 ve Gelece\u011fe Bak\u0131\u015f<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
\n