{"id":864,"date":"2019-03-30T12:51:45","date_gmt":"2019-03-30T12:51:45","guid":{"rendered":"http:\/\/www.yazilimperver.com\/?p=864"},"modified":"2019-03-30T17:58:00","modified_gmt":"2019-03-30T17:58:00","slug":"haftalik-c-12-multithread-programlamada-karsilasilan-bazi-sikintilar","status":"publish","type":"post","link":"https:\/\/www.yazilimperver.com\/index.php\/2019\/03\/30\/haftalik-c-12-multithread-programlamada-karsilasilan-bazi-sikintilar\/","title":{"rendered":"Haftal\u0131k C++ 12 – Multithread programlamada kar\u015f\u0131la\u015f\u0131lan baz\u0131 s\u0131k\u0131nt\u0131lar"},"content":{"rendered":"

<\/p>\n

\"\"<\/p>\n

Merhabalar dostlar. K\u0131sa bir aradan sonra, ba\u015fka bir haftal\u0131k C++ yaz\u0131s\u0131 ile birlikteyiz. Bu yaz\u0131mda, bir s\u00fcre \u00f6nce sizler ile payla\u015ft\u0131\u011f\u0131m thread k\u00fct\u00fcphanesinin kullan\u0131m\u0131 ile ilgili baz\u0131 hatal durumlar\u0131 ve bunlar\u0131 nas\u0131l \u00f6nleyebilece\u011fimize bakaca\u011f\u0131z. Her bir duruma ayr\u0131 ba\u015fl\u0131klarda, k\u0131sa a\u00e7\u0131klama ve \u00f6rnekler ile de\u011finece\u011fiz. Buradaki durumlar\u0131n bir k\u0131sm\u0131n\u0131, yaz\u0131lar\u0131m\u0131 takip edenleriniz hat\u0131rlayacakt\u0131r, ilgili konular\u0131 anlat\u0131rken bunlara da k\u0131saca de\u011finmi\u015ftim. <\/span><\/p>\n

Bu yaz\u0131m i\u00e7in ise kaynak\u00e7ada verdi\u011fim siteden faydaland\u0131m. Asl\u0131nda bu yaz\u0131y\u0131 thread yaz\u0131lar\u0131n\u0131 yazarken g\u00f6rm\u00fc\u015ft\u00fcm ama o zaman seriyi tamamlamad\u0131\u011f\u0131m i\u00e7in vermek istemedim, ama \u015fimdi tam zaman\u0131. O yaz\u0131da 20 ye yak\u0131n durumdan bahsedilse de, ben bu yaz\u0131mda bana g\u00f6re \u00f6nemli oldu\u011funu d\u00fc\u015f\u00fcnd\u00fcklerimi ekledim. Bu yaz\u0131 ile birlikte, bu tarz hatal\u0131 durumlar\u0131 toplu bir \u015fekilde inceleme \u015fans\u0131n\u0131z olacak, hem de thread k\u00fct\u00fcphanesinin h\u0131zl\u0131 bir tekrar\u0131n\u0131 yapm\u0131\u015f olaca\u011f\u0131z. Yaz\u0131m\u0131n sonuna ayr\u0131ca, multithreaded programlama ile ilgili faydalanabilece\u011finiz ba\u011flant\u0131lar da ekledim. Yine benzer i\u00e7erikleri sizler ile payla\u015f\u0131yor olaca\u011f\u0131m. <\/span><\/p>\n

Evet daha fazla beklemeden ilgili problemlere bakmaya ba\u015flayal\u0131m:<\/span><\/p>\n

1. Farkl\u0131 thread\u2019ler taraf\u0131ndan kullan\u0131lacak verilerin koruma alt\u0131na al\u0131nmamas\u0131:<\/b><\/span><\/h2>\n

Bir \u00f6nceki yaz\u0131m\u0131zda<\/a> <\/strong>g\u00f6rd\u00fc\u011f\u00fcm\u00fcz \u00fczere, multithreaded programlama\u2019da kar\u015f\u0131la\u015faca\u011f\u0131n\u0131z en yayg\u0131n problem, thread\u2019ler aras\u0131 payla\u015f\u0131lan verilerin korunmamas\u0131d\u0131r. <\/span><\/p>\n

Siz zaten bu problemi ve bunu nas\u0131l \u00e7\u00f6zebilece\u011finizi bir \u00f6nceki yaz\u0131mdan biliyorsunuzdur \ud83d\ude42 Evet, do\u011fru tahmin ettiniz, ilgili kritik b\u00f6lgeleri std::mutex<\/em> ve benzeri yap\u0131lar ile korumak. Bu sayede, ilgili veriye ayn\u0131 anda sadece bir thread\u2019in eri\u015fti\u011fini teminat alt\u0131na alm\u0131\u015f olacaks\u0131n\u0131z. Peki burada ger\u00e7ekle\u015ftirilen olay neydi? Temel olarak ger\u00e7ekle\u015ftirilen: payla\u015f\u0131lan veri ile \u00e7al\u0131\u015facak thread, ilgili kritik b\u00f6lgeye girmeden \u00f6nce, std::mutex<\/em>\u2019i kilitler ve veri ile olan i\u015fini ger\u00e7ekle\u015ftirir ve sonras\u0131nda bu kilidi kald\u0131r\u0131r. Bu sayede, ilgili veri ile \u00e7al\u0131\u015fmak isteyen di\u011fer threadler bu veri \u00fczerinde \u00e7al\u0131\u015fabilir ve g\u00fcvenli bir \u015fekilde g\u00fcncelleyebilirler.<\/span><\/p>\n

Burada elbette s\u0131k\u0131nt\u0131l\u0131 durumun, herhangi bir thread\u2019in, payla\u015f\u0131lan veriyi g\u00fcncellemek istedi\u011fi durumunda olu\u015faca\u011f\u0131n\u0131 hat\u0131rlatmak istiyorum. Yoksa, e\u011fer b\u00fct\u00fcn thread\u2019ler payla\u015f\u0131lan verileri sadece okuyor\/kullan\u0131yor ise, herhangi bir problem ile kar\u015f\u0131la\u015fmayacaks\u0131n\u0131z. <\/span><\/p>\n

Bu ba\u015fl\u0131k biraz bunu hat\u0131rlatmaya y\u00f6nelikti.<\/span><\/p>\n

2. Kritik b\u00f6lge kilidinin kald\u0131r\u0131lmamas\u0131:<\/b><\/span><\/h2>\n

Bir \u00f6nceki problemde, ortak verilere, birden fazla thread taraf\u0131ndan eri\u015fip, tutarl\u0131 bir \u015fekilde kullan\u0131lmas\u0131 i\u00e7in, std::mutex<\/em> ve benzeri yap\u0131lar\u0131n kullan\u0131lmas\u0131 gerekti\u011fini ifade ettik ve nas\u0131l kullan\u0131laca\u011f\u0131n\u0131 basit bir \u00f6rnek ile g\u00f6sterdik. Peki bunlar\u0131 do\u011fru kullanmazsak ne olur? \u00d6rne\u011fin, ilgili kritik b\u00f6lgeye girdi\u011finizde kilidi aktfile\u015ftirdiniz ama i\u015finiz bitti\u011finde, kilidi kald\u0131rmad\u0131n\u0131z ne olacak? Evet, do\u011fru tahmin ettiniz, bu veriye eri\u015fip, kullanmak isteyen di\u011fer thread\u2019ler, bu veriye eri\u015fmek a\u015fk\u0131 ile yan\u0131p k\u00fcl olacaklar ama yine de eri\u015femeyecekler. Sonu\u00e7 olarak, uygulaman\u0131z as\u0131l\u0131 kalacak.\u00a0<\/span><\/p>\n

Peki bunu \u00f6nlemek i\u00e7in ne yapabiliriz? Bu ama\u00e7la sunulan, yard\u0131mc\u0131 yap\u0131lar\u0131 kullanabiliriz (tabi kilidi ilgili API’yi kullanarak kald\u0131rman\u0131n yan\u0131nda), bunlar\u0131n da en \u00f6nemlisi, std::mutex<\/em> ve ilgili kilitleme\/kilidi kald\u0131rma API\u2019leri yerine, RAII (Resource Acquisition Is Initialization)<\/em> tabanl\u0131 <\/span>std::lock_guard <\/i><\/b>benzeri yap\u0131lar\u0131 daha s\u0131k kullanmak olacakt\u0131r. Bu sayede, kilidi kald\u0131rmay\u0131 unutma gibi bir derdiniz de olmayacak. Ne zamanki lock_guard<\/em> nesneleri, tan\u0131ml\u0131 kapsamlar\u0131 d\u0131\u015f\u0131nda \u00e7\u0131k\u0131nca, otomatik olarak ilgili mutex\u2019lerin kilidini kald\u0131r\u0131yor olacaklar. <\/span><\/p>\n

Asl\u0131nda, her ne kadar bu yakla\u015f\u0131m \u00e7ok uzun bir s\u00fcredir bilinse de, modern C++ bunu ak\u0131ll\u0131 i\u015faret\u00e7iler ve benzeri yard\u0131mc\u0131 yap\u0131lar ile daha kolayla\u015ft\u0131rd\u0131. Bana kal\u0131rsa, bu tarz yap\u0131lar\u0131n, bir di\u011fer avantaj\u0131 da kodu daha okunabilir yapmalar\u0131.\u00a0<\/span><\/p>\n

3. \u0130lgili std::mutex\u2019in iki kere kilitlenmesi:<\/b><\/span><\/h2>\n

Herhangi bir mutex\u2019in iki kere kilitlenmesi bir \u00e7ok thread k\u00fct\u00fcphanesinde, beklenmedik davran\u0131\u015flara sebep olabilir ve bu da \u00e7o\u011funlukla uygulaman\u0131n \u00e7ak\u0131lmas\u0131 \u015feklinde ortaya \u00e7\u0131kacakt\u0131r. Burada dikkat edilecek iki durum var: birincisi, ilgili mutex\u2019in yanl\u0131\u015fl\u0131kla iki kere kilitlenmesi di\u011fer ise b\u00f6yle bir ihtiyac\u0131n olmas\u0131. <\/span><\/p>\n

\u0130lki i\u00e7in dikkatli olmak ve ilgili hatay\u0131 d\u00fczeltmekten ba\u015fka \u00e7areniz yok ama ikincisi i\u00e7in bir \u00f6nceki yaz\u0131mda bahsetti\u011fim<\/a><\/span><\/strong> std::recursive_mutex<\/em> s\u0131n\u0131f\u0131n\u0131 kullanabilirisiniz (iligli yaz\u0131da Calculator s\u0131n\u0131f\u0131nda buna ili\u015fkin bir \u00f6rne\u011fe bakm\u0131\u015ft\u0131k). Tabi, ilk durumda bahsetti\u011fim hatay\u0131 \u00f6nlemek i\u00e7in de std::recursive_mutex<\/em> kullanabilirsiniz ama bu do\u011fru bir yakla\u015f\u0131m de\u011fil ve bunu yapmamal\u0131s\u0131n\u0131z \ud83d\ude42<\/span><\/p>\n

4. Korunmas\u0131 gereken kritik b\u00f6lgeyi uzun tutmak<\/b><\/span><\/h2>\n

Bir di\u011fer g\u00f6z \u00f6n\u00fcnde bulundurulmas\u0131 gereken ve \u00f6zellikle beklenmedik beklemelere yol a\u00e7an durum, kritik b\u00f6lgelerin uzun tutulmas\u0131. Bir di\u011fer ifade ile, bu b\u00f6lgelerde yap\u0131lan i\u015flerin \u00e7ok fazla olmas\u0131. Burada amac\u0131m\u0131z basit: bu b\u00f6lgelerde yap\u0131lan i\u015fleri olabildi\u011fince azaltmak, payla\u015f\u0131lan kritik veri ile ilgili olmaya b\u00fct\u00fcn i\u015fleri, bu b\u00f6lge d\u0131\u015f\u0131nda, mutex\u2019in kapsam\u0131 d\u0131\u015f\u0131nda, tutmak. Bu anlamda, std::scoped_lock<\/em> s\u0131n\u0131flar\u0131n\u0131 kullanman\u0131z\u0131 \u00f6neriyorum.<\/span><\/p>\n

5. \u00c7oklu mutex kullan\u0131lmas\u0131 durumunda, kilitleme s\u0131ras\u0131n\u0131n kar\u0131\u015ft\u0131r\u0131lmas\u0131<\/b><\/span><\/h2>\n

Geldik, bir di\u011fer \u00f6nemli probleme. Bir \u00f6nceki yaz\u0131mda, \u201cdeadlock<\/em>\u201d durumundan, yani thread\u2019lerin birbirlerini sonsuza dek beklemeleri durumundan bahsetmi\u015ftim. \u0130\u015fte bunun en \u00f6nemli sebeplerinden birisi de bu. Yani birden fazla thread\u2019in, birden fazla mutex\u2019i farkl\u0131 s\u0131ralar ile kilitleyip, kilidini kald\u0131rmaya \u00e7al\u0131\u015fmas\u0131. \u00d6ncelikle iki thread i\u00e7in bu durumun nas\u0131l olabilece\u011fine bakal\u0131m:<\/span><\/p>\n\n\n\n\n
Thread 1<\/b><\/td>\nThread 2<\/b><\/td>\n<\/tr>\n
A Mutex\u2019ini kilitle<\/strong><\/p>\n

\/\/.. Bir \u015feyler yapal\u0131m<\/p>\n

B Mutex\u2019ini kilitle<\/strong><\/p>\n

\/\/ .. Daha da bir \u015feyler yapal\u0131m<\/p>\n

B Mutex\u2019inin kilidini kald\u0131r<\/p>\n

A Mutex\u2019inin kilidini kald\u0131r<\/td>\n

B Mutex\u2019ini kilitle<\/strong><\/p>\n

\/\/.. Bir \u015feyler yapal\u0131m<\/p>\n

A Mutex\u2019ini kilitle<\/strong><\/p>\n

\/\/.. Daha da bir \u015feyler yapal\u0131m<\/p>\n

A Mutex\u2019inin kilidini kald\u0131r<\/p>\n

B Mutex\u2019inin kilidini kald\u0131r<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u015eimdi Thread 1\u2019in A mutex\u2019inin kilitledi\u011fi s\u0131rada, Thread 2\u2019nin de B Mutex\u2019ini kilitledi\u011fini d\u00fc\u015f\u00fcnelim. Ne olur? Thread 1, B mutex\u2019ini kilitlemeye \u00e7al\u0131\u015ft\u0131\u011f\u0131 zaman, bu mutex, A taraf\u0131ndan kilitlendi\u011fi i\u00e7in bloklanacak ve bekleyecek. Benzer \u015fekilde Thread 2\u2019de A mutexi i\u00e7in bekleyecek ve \u201cDeadlock\u201d dedi\u011fimiz durum, i\u015fte tam bu noktada olu\u015facak.<\/p>\n

\"\"<\/p>\n

A\u015fa\u011f\u0131da verilen \u00f6rnek kod, burada bahsetti\u011fimiz durumu ortaya koyuyor:<\/p>\n

#include <iostream>\r\n#include <string>\r\n#include <thread>\r\n#include <mutex>\r\n\r\nusing namespace std;\r\n\r\nstd::mutex muA;\r\nstd::mutex muB;\r\n\r\nvoid printMessage1(const string& message)\r\n{\r\n\tmuA.lock();\r\n\r\n\t\/\/ Biraz bekleme\r\n\tstd::this_thread::sleep_for(std::chrono::milliseconds(100));\r\n\r\n\tmuB.lock();\r\n\tcout << \"Thread \" << this_thread::get_id() << \" says \" << message << endl;\r\n\tmuB.unlock();\r\n\tmuA.unlock();\r\n\r\n}\r\n\r\nvoid printMessage2(const string& message)\r\n{\r\n\tmuB.lock();\r\n\r\n\t\/\/ Biraz bekleme\r\n\tstd::this_thread::sleep_for(std::chrono::milliseconds(100));\r\n\r\n\tmuA.lock();\r\n\tcout << \"Thread \" << this_thread::get_id() << \" says \" << message << endl;\r\n\t\r\n\tmuA.unlock();\r\n\tmuB.unlock();\r\n}\r\n\r\nint main()\r\n{\r\n\tthread t1(printMessage1, \"Hello from Jupiter\");\r\n\tthread t2(printMessage2, \"Hello from Pluto\");\r\n\r\n\tt1.join();\r\n\tt2.join();\r\n\treturn 0;\r\n}<\/pre>\n
Peki bu durumu \u00f6nlemek i\u00e7in ne yapacaks\u0131n\u0131z? \u00d6ncelikle, bu tarz \u00e7oklu mutex kullan\u0131lmas\u0131 durumunda ayn\u0131 s\u0131ray\u0131 takip etmek olacakt\u0131r.<\/p>\n
Ayr\u0131ca, yine bir \u00f6nceki yaz\u0131mda bahsetti\u011fim ve \u00e7oklu mutex alan std::scoped_lock<\/em> tarz\u0131 s\u0131n\u0131flar\u0131 kullanmak olacakt\u0131r.<\/p>\n
\/\/ Coklu mutex kilitlenir\r\nstd::scoped_lock lock{muA, muB};<\/pre>\n
6. join()\/detach() metotlar\u0131n\u0131 \u00e7a\u011f\u0131rmay\u0131 unutmak<\/b><\/span><\/h2>\n
Asl\u0131nda ba\u015fl\u0131k, ilgili problemi net bir \u015fekilde tan\u0131ml\u0131yor. Peki neden bu metotlar\u0131 \u00e7a\u011f\u0131rmaya ihtiya\u00e7 duyuyoruz ve \u00e7a\u011f\u0131rmaz isek ne olur? E\u011fer thread\u2019lerin tamamlanmas\u0131n\u0131 beklemeden <\/span>main()\u00a0<\/span><\/i>metodundan \u00e7\u0131karsan\u0131z, thread\u2019ler i\u015flerini d\u00fczg\u00fcn bir \u015fekilde tamamlamad\u0131klar\u0131 i\u00e7in, b\u00fct\u00fcn uygulaman\u0131z\u0131n g\u00f6\u00e7t\u00fc\u011f\u00fcn\u00fc g\u00f6receksiniz. <\/span><\/p>\n
Bu sebeple thread\u2019ler ile \u00e7al\u0131\u015f\u0131rken, birle\u015ftirmek i\u00e7in <\/span>join()<\/span><\/i> ya da ay\u0131rmak i\u00e7in <\/span>detach()<\/span><\/i> API\u2019lerini \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131zdan muhakkak emin olun. <\/span>join()<\/span><\/i> API\u2019si bu metodu \u00e7a\u011f\u0131ran thread\u2019i ilgili thread bitene kadar bekletir ve ilgili thread bitince \u00e7al\u0131\u015fmaya devam eder. E\u011fer \u00e7a\u011f\u0131ran thread\u2019in ilgili thread\u2019i beklemesini istemiyorsan\u0131z o zaman da <\/span>detach()<\/span><\/i> API\u2019sini kullan\u0131rs\u0131n\u0131z ve bu durumda \u00e7a\u011f\u0131ran thread, arka planda \u00e7al\u0131\u015fmaya devam eder. Bu noktadan sonra, ilgili thread \u00fczerinde herhangi bir kontrol\u00fc de olmaz.<\/span><\/p>\n
Daha detayl\u0131 bilgi i\u00e7in ilk thread yaz\u0131ma<\/a><\/strong><\/span> g\u00f6z atabilirsiniz.<\/span><\/p>\n
7. Daha \u00f6nce detach() ile ayr\u0131lm\u0131\u015f bir thread i\u00e7in join() API\u2019sini \u00e7a\u011f\u0131rma<\/b><\/span><\/h2>\n
Bir \u00f6nceki ba\u015fl\u0131kta da ifade etti\u011fimiz gibi, daha \u00f6nce detach()<\/em> ile ayr\u0131lm\u0131\u015f olan bir thread \u00fczerinde art\u0131k herhangi bir kontrol\u00fcn\u00fcz kalm\u0131yor. Bir \u015fekilde e\u011fer bu thread\u2019e ili\u015fkin olarak join()<\/em> \u00e7a\u011f\u0131r\u0131rsan\u0131z (tabi normal \u015fartlarda bunu \u00e7a\u011f\u0131rmazs\u0131n\u0131z, fakat e\u011fer ilgili kodlar farkl\u0131 yerlerde ise g\u00f6z\u00fcn\u00fczden ka\u00e7abilir), uygulaman\u0131z \u00e7\u00f6ker. Peki ne yapaca\u011f\u0131z? Bu durum i\u00e7in thread k\u00fct\u00fcphanesi bir API sunmakta: joinable()<\/em><\/strong>. E\u011fer thread data \u00f6nce ayr\u0131lm\u0131\u015f ise, bu API false d\u00f6necektir, aksi takdirde true d\u00f6necektir.<\/span><\/p>\n
8. join() API\u2019sinin davran\u0131\u015f\u0131<\/strong><\/span><\/h2>\n
Bir \u00f6nceki API ile ilintili olarak, e\u011fer \u00e7al\u0131\u015fan bir thread\u2019e ili\u015fkin join()<\/em> API\u2019sini \u00e7a\u011f\u0131r\u0131rsan\u0131z, ilgili API mevcut thread ko\u015fumunu, \u00e7a\u011fr\u0131lan thread tamamlanana kadar bloklar. Bu sebeple, bu API\u2019den \u00f6nce ya ilgili thread\u2019in i\u015finin bitti\u011finden emin olun ya da yaz\u0131l\u0131m\u0131n\u0131z\u0131 bu do\u011frultuda tasarlay\u0131n.<\/span><\/p>\n
9. Thread arg\u00fcmanlar\u0131n\u0131n referans olarak ge\u00e7irildi\u011fini d\u00fc\u015f\u00fcnmek<\/b><\/span><\/h2>\n
\u0130lk thread yaz\u0131mda<\/a><\/strong><\/span> bir \u00f6rnek \u00fczerinden g\u00f6sterdi\u011fim bir durumdu bu. Ne demi\u015ftik bakal\u0131m: <\/span><\/p>\n
Her ne kadar, thread metodu parametreyi referans olarak al\u0131yor olsa da, yeni thread olu\u015fturulurken ilgili de\u011fi\u015fkeni arka tarafta kopyalan\u0131r ve thread \u00e7al\u0131\u015fmaya ba\u015flad\u0131\u011f\u0131nda da bu kopyay\u0131 metoda ge\u00e7irir. Bu sebeple, yeni olu\u015fturulan thread \u00e7al\u0131\u015fmay\u0131 tamamland\u0131\u011f\u0131nda, thread metodundaki de\u011fi\u015fken, thread metoduna ge\u00e7irilen ve kopyalar\u0131 olu\u015fturulan di\u011fer parametreler ile birlikte yok edilir. Bu sebeple de as\u0131l de\u011fi\u015fken g\u00fcncellenmez. Bu problemi \u00f6nlemek ve parametrenin kendisini i\u00e7eren bir referans g\u00f6ndermek i\u00e7in yine STL taraf\u0131ndan sunulan std::ref()<\/em> fonksiyonu kullan\u0131lmal\u0131d\u0131r. Nas\u0131l kullanaca\u011f\u0131z? A\u015fa\u011f\u0131daki gibi:<\/span><\/p>\n
\/\/ Thread'e 'str' de\u011fi\u015fkeninin referans\u0131n\u0131 ge\u00e7irmek istiyoruz\r\nstd::thread newThread(execute, std::ref(str));<\/pre>\n
10. std::atomic tipinin kullan\u0131m\u0131<\/b><\/h2>\n
\u0130kinci thread yaz\u0131mda<\/a> <\/strong><\/span>bahsetti\u011fim gibi, temel ve basit veri tipleri i\u00e7in std::atomic<\/em> mekanizmas\u0131n\u0131 kullanabiliriz. Bu bize hem performans hem de okunabilirlik ad\u0131na bir\u00e7ok fayda sa\u011flar. std::mutex<\/em> kullanabilir miyiz? Elbette, ama atomic kullan\u0131m\u0131 bizim i\u00e7in performans a\u00e7\u0131s\u0131ndan ciddi fark yaratabilir. <\/span>https:\/\/www.arangodb.com\/2015\/02\/comparing-atomic-mutex-rwlocks\/<\/a><\/span><\/strong> sitesinde bunun ile ilgili g\u00fczel bir \u00e7al\u0131\u015fma var.<\/span><\/p>\n
11. std::future nesnesine ili\u015fkin get() API\u2019sinin bilin\u00e7siz bir \u015fekilde \u00e7a\u011fr\u0131lmas\u0131<\/b><\/span><\/h2>\n
\u015eimdi de eski yaz\u0131lar\u0131mda bahsetti\u011fim bir s\u0131n\u0131f olan, std::future<\/em> nesnesine ili\u015fkin bir duruma g\u00f6z atal\u0131m. O yaz\u0131mda da bahsetti\u011fim gibi, e\u011fer bu nesnenin i\u015fi hen\u00fcz bitmemi\u015f ise ve get()<\/em> metodu \u00e7a\u011fr\u0131l\u0131rsa, ilgili i\u015f bitene kadar, mevcut thread bloklan\u0131r ki bunu genelde istemeyiz. Hemen bir \u00f6rnek \u00fczerinden bu duruma bakal\u0131m:<\/span><\/p>\n
#include <future>\r\n#include <iostream>\r\n\r\nint main()\r\n{\r\n  std::future<int> myFuture = std::async(std::launch::async, []()\r\n  {\r\n    std::this_thread::sleep_for(std::chrono::seconds(10));\r\n    return 8;\r\n  });\r\n  \r\n  \/\/ veri i\u015fleme d\u00f6ng\u00fcs\u00fc\r\n  while (true)\r\n  {\r\n    \/\/ Konsola bir seyler bastiralim \r\n    std::cout << \"Processing Data\" << std::endl;\r\n    \r\n     \/\/ Bu kod 10 sn mevcut threadi bloklar\r\n    int val = myFuture.get(); \r\n  }\r\n  return 0;\r\n}<\/pre>\n
Yukar\u0131da verilen kodta, nerede bloklama olaca\u011f\u0131n\u0131 g\u00f6rebilirsiniz. Bu kod ile ilgili bir di\u011fer s\u0131k\u0131nt\u0131 da, ilgili std::future<\/em> nesnesi bir kere al\u0131n\u0131p, art\u0131k al\u0131nacak bir \u015fey olmamas\u0131na ra\u011fmen, bunun sorgulanmas\u0131d\u0131r.Bunu \u00f6nlemek i\u00e7in, ilgili nesnenin haz\u0131r olur olmad\u0131\u011f\u0131n\u0131 kontrol edebiliriz. Bunu da valid()<\/em> API si ile yapabiliriz. \u015e\u00f6yleki:<\/span><\/p>\n
#include <future>\r\n#include <iostream>\r\n\r\nint main()\r\n{\r\n  std::future<int> myFuture = std::async(std::launch::async, []()\r\n  {\r\n    std::this_thread::sleep_for(std::chrono::seconds(10));\r\n    return 8;\r\n  });\r\n  \r\n  \/\/ \u0130\u015flem yapan d\u00f6ng\u00fc\r\n  while (true)\r\n  {\r\n    \/\/ Konsola bir seyler bastiralim\r\n    std::cout << \"Veri i\u015fleniyor\" << std::endl;\r\n\r\n    if (myFuture.valid())\r\n    {\r\n       \/\/ mevcut thread 10 sn bekleyecek\r\n      int val = myFuture.get();\r\n    }\r\n  }\r\n  return 0;\r\n}<\/pre>\n
12. std::async i\u00e7erisinde ger\u00e7ekle\u015fen istisna (exception) durumlar\u0131 std::future nesnesine get() API\u2019si ile ge\u00e7irilmesi<\/b><\/span><\/h2>\n
 E\u011fer std::async<\/em> kullan\u0131yorsan\u0131z ve bunun i\u00e7erisinde bir istisnai durum olu\u015ftu ise bunu \u00e7a\u011f\u0131ran tarafa ge\u00e7irmek i\u00e7in de get()<\/em> API\u2019sini \u00e7a\u011f\u0131rmal\u0131s\u0131n\u0131z. A\u015fa\u011f\u0131da buna dair \u00f6rnek bir kullan\u0131m g\u00f6sterelim:<\/span><\/p>\n
#include <future>\r\n#include <iostream>\r\n\r\nint main()\r\n{\r\n   std::future<int> myFuture = std::async(std::launch::async, []() \r\n   {\r\n        throw std::runtime_error(\"Catch me in MAIN\");\r\n        return 8;\r\n    });\r\n\r\n    if (myFuture.valid())\r\n    {\r\n        try\r\n        {\r\n            int result = myFuture.get();\r\n        }\r\n        catch (const std::runtime_error& e)\r\n        {\r\n            std::cout << \"Async task threw exception: \" << e.what() << std::endl;\r\n        }\r\n    }\r\n   \r\n   return 0;\r\n}<\/pre>\n
13. Mevcut \u00e7ekirdek say\u0131s\u0131nda \u00e7ok daha fazla thread olu\u015fturulmas\u0131<\/b><\/span><\/h2>\n
\u0130lk thread yaz\u0131mda<\/a><\/strong><\/span> da bahsetti\u011fimiz gibi, ayn\u0131 anda \u00e7al\u0131\u015fabilecek thread say\u0131s\u0131, mevcut i\u015flemcinin bizlere sundu\u011fu \u00e7ekirdek say\u0131s\u0131 ile ilintilidir. E\u011fer ilgili thread say\u0131s\u0131 bundan fazla ise, fazladan thread olu\u015fturmak, bize performans anlam\u0131nda ciddi bir kazan\u0131m sa\u011flamaz, hatta k\u00f6t\u00fc y\u00f6nde de etkileyebilir.<\/span><\/p>\n
Evet arkada\u015flar, bir yaz\u0131m\u0131z\u0131n daha sonuna geldik. Umar\u0131m thread’ler konusunda sizlere yard\u0131mc\u0131 olacak bir kaynak olmu\u015ftur. Buradaki konular\u0131n yan\u0131nda, daha detayl\u0131 bilgi i\u00e7in a\u015fa\u011f\u0131daki sitelere de g\u00f6z atmay\u0131 unutmay\u0131n. Bir sonraki yaz\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere.<\/p>\n
Kaynaklar:<\/strong><\/span><\/h2>\n