মাল্টিথ্রেডিং — thread, mutex আর condition_variable

১ · কেন thread — এক রান্নাঘরে কয়েকজন রাঁধুনি

এ পর্যন্ত আপনার লেখা প্রতিটি প্রোগ্রাম একটি সরল রেখায় চলেছে: একটি লাইন শেষ, তারপর পরেরটি। আজকের কম্পিউটারে এটা অনেকটা এমন, যেন একটি বড় রান্নাঘরে চারটি চুলা আছে, অথচ রাঁধছেন একজনই। একটি প্রোগ্রামের ভেতরে স্বাধীনভাবে চলা প্রতিটি কাজের ধারাকে বলে thread. এক প্রোগ্রামে কয়েকটি thread মানে এক রান্নাঘরে কয়েকজন রাঁধুনি।

Process আর thread

অপারেটিং সিস্টেমে চলমান প্রতিটি প্রোগ্রাম একটি process. প্রতিটি process-এর মেমরি আলাদা — যেন আলাদা আলাদা দোকান, যার রান্নাঘর অন্যজন ছুঁতে পারে না। একটি process-এর ভেতরের সব thread কিন্তু একই মেমরি ভাগ করে: global ভ্যারিয়েবল, heap-এর object, খোলা ফাইল — সব। শুধু প্রত্যেকের নিজের stack আলাদা, যেন প্রত্যেক বাবুর্চির নিজের কাটার বোর্ড। তাই thread-দের মধ্যে তথ্য আদান-প্রদান খুব সস্তা (একই মেমরি), আবার ঠিক সেই কারণেই বিপজ্জনক।

Concurrency আর parallelism — এক নয়

এক core-এ এক thread থেকে আরেক thread-এ যেতে অপারেটিং সিস্টেম আগের thread-এর অবস্থা সেভ করে, নতুনটির অবস্থা ফিরিয়ে আনে — একে বলে context switch. এটি দ্রুত, কিন্তু বিনা খরচে নয়। আপনার কোড এক core-এ চলছে নাকি আট core-এ, তা সাধারণত আপনি জানেন না, আর জানার দরকারও নেই — সঠিক প্রোগ্রাম দুই অবস্থাতেই সঠিক থাকবে।

কখন thread লাভজনক, আর কখন নয়

খরচ শুধু সময়ের নয়। প্রতিটি thread-এর নিজের stack-এর জন্য মেমরি সংরক্ষিত থাকে, আর সবচেয়ে বড় খরচ জটিলতা: thread-এর বাগ প্রতিবার চালালে দেখা দেয় না, আজ ঠিক চলে, কাল গ্রাহকের মেশিনে ভেঙে পড়ে। মেশিন একসাথে আনুমানিক কতগুলো thread সত্যিই চালাতে পারে, তা জানায় hardware_concurrency() — কিন্তু এটি শুধু ইঙ্গিত, মেশিনভেদে আলাদা, আর জানা না গেলে 0 ফেরত দিতে পারে।

২ · std::thread আর std::jthread — শুরু, join আর detach

C++11 থেকে standard library-তে আছে std::thread (<thread> header). একটি thread object তৈরি করা মানেই নতুন thread চলা শুরু — আলাদা কোনো “start” ডাকতে হয় না। কী চালাবে, তা constructor-এ দেন: একটি সাধারণ ফাংশন, একটি lambda (পর্ব ৩৪), বা যেকোনো ডাকা যায় এমন জিনিস।

#include <thread>

void cookRice()  { /* ভাত রান্না */ }

int main() {
    std::thread t1(cookRice);                    // এই মুহূর্তে নতুন thread চলা শুরু
    std::thread t2([] { /* মাংস রান্না */ });     // lambda-ও চলে
    t1.join();                                   // t1 শেষ হওয়া পর্যন্ত main অপেক্ষা করে
    t2.join();
}

এখন তিনটি thread একসাথে চলছে: main নিজে, t1 আর t2. কোনটি আগে শেষ হবে, কোনটির লাইন আগে চলবে — কোনো নিশ্চয়তা নেই। সেটা অপারেটিং সিস্টেমের সময়-বণ্টনের ওপর নির্ভর করে, আর প্রতিবার আলাদা হতে পারে।

join না detach — রাঁধুনিকে বিদায় দেবেন কীভাবে?

প্রতিটি std::thread-এর জীবনে আপনাকে একটি সিদ্ধান্ত নিতেই হবে। join() মানে “এই thread-এর কাজ শেষ হওয়া পর্যন্ত আমি অপেক্ষা করব” — দোকান বন্ধের আগে মালিক সব বাবুর্চির রান্না শেষ হওয়ার জন্য দাঁড়িয়ে থাকেন। join-এর পর thread-এর সব লেখা নিরাপদে পড়া যায়। detach() মানে “এই thread নিজের মতো চলুক, আমি আর খোঁজ নেব না।” detach করা thread-এর জন্য আর অপেক্ষা করা যায় না, আর main শেষ হলে process বন্ধ হয় — তখন সে কাজের মাঝপথেই থেমে যায়।

যদি দুটির কোনোটিই না করেন? যে std::thread এখনো একটি thread ধরে আছে, তাকে বলে joinable. joinable অবস্থায় তার destructor চললে C++ সোজা std::terminate ডাকে — প্রোগ্রাম সঙ্গে সঙ্গে বন্ধ। এটা ইচ্ছাকৃত কঠোরতা (কেন, তা ভাবনার প্রশ্ন ৩-এ)। সমস্যা হলো, মাঝে একটি exception উড়লে আপনার t.join() লাইনে পৌঁছানোই হয় না।

void serve() {
    std::thread t(cookRice);
    prepareTable();          // এখানে exception হলে...
    t.join();                // ...এই লাইনে পৌঁছায় না → t joinable অবস্থায় ধ্বংস → terminate
}

চেনা সমস্যা, তাই না? পর্ব ১৭-এ ঠিক এটাই দেখেছেন: “মনে রেখে ফেরত দেওয়া” মানুষ নির্ভরযোগ্যভাবে পারে না। সমাধানও একই — RAII. C++20 এনেছে std::jthread (“joining thread”): এর destructor নিজেই থামার অনুরোধ পাঠায় আর join করে। exception উড়ুক বা আগেভাগে return হোক, thread-এর জন্য অপেক্ষা নিশ্চিত।

void serve() {
    std::jthread t(cookRice);   // C++20
    prepareTable();             // exception হলেও t-এর destructor join করবে
}                               // এখানে নিজে থেকেই join

দুটিই কপি করা যায় না, কারণ একটি চলমান thread-এর মালিক একজনই হতে পারে — ঠিক পর্ব ১৭-এর unique_ptr-এর মতো। হাতবদল করতে std::move লাগে (পর্ব ৩৬)। তাই std::vector<std::jthread>-এ অনেকগুলো thread রাখা যায়, আর vector ধ্বংস হলে সবগুলো join হয়।

৩ · Thread-এ argument পাঠানো — কপি, std::ref আর dangling-এর ফাঁদ

thread-এর ফাংশনে argument দিতে চাইলে সেগুলো constructor-এ ফাংশনের পরে লিখে দেন: std::jthread t(f, a, b);. এখানে একটি নিয়ম অনেককে চমকে দেয়: thread সব argument ডিফল্টভাবে কপি করে (বা move করে), নিজের কাছে রেখে দেয়। কারণ নতুন thread কখন চলবে আর কতক্ষণ চলবে, তা অজানা। তাই আসল ভ্যারিয়েবলের ওপর ভরসা না রেখে নিজের কপি রাখাই নিরাপদ ডিফল্ট।

void addBonus(int& salary, int taka) { salary += taka; }

int salary = 30000;
std::jthread t1(addBonus, salary, 500);             // compile error: কপি int&-এ বাঁধে না
std::jthread t2(addBonus, std::ref(salary), 500);   // ঠিক: আসল salary-র reference যায়

ফাংশনটি int& চাইলেও thread একটি কপি বানিয়ে পাঠাতে চায়, তাই compiler আটকে দেয় — এটা ভালো খবর, ভুলটা চলার আগেই ধরা পড়ল। সত্যিই আসল ভ্যারিয়েবল পাঠাতে চাইলে std::ref দিয়ে মুড়ে দিন (const reference-এর জন্য std::cref). কিন্তু মনে রাখুন, std::ref লেখা মানে আপনি একটি প্রতিশ্রুতি দিলেন: thread শেষ হওয়া পর্যন্ত ভ্যারিয়েবলটি বেঁচে থাকবে, আর এর মধ্যে অন্য কেউ একে ছোঁবে না, অথবা ছুঁলে তালা দিয়ে।

সবচেয়ে বিপজ্জনক ফাঁদ — মরে যাওয়া ভ্যারিয়েবলের reference

lambda-তে [&] দিয়ে capture করলে (capture by reference) একই প্রতিশ্রুতি লুকিয়ে দেওয়া হয়। পর্ব ১৮-এ দেখেছেন, ফাংশন শেষ হলে তার local ভ্যারিয়েবল মরে যায়। thread যদি তখনো চলতে থাকে, তার হাতে থাকে একটি dangling reference:

void startReport() {
    std::string file = "sales.csv";
    std::thread t([&file] { process(file); });   // file-এর reference
    t.detach();                                  // thread নিজের মতো চলল
}   // file এখানেই ধ্বংস — অথচ thread হয়তো এখনো file পড়ছে → undefined behavior

// সমাধান: thread-কে নিজের কপি দিন
std::jthread t([file] { process(file); });       // file-এর কপি thread-এর ভেতরে

এই বাগটা কপট: আপনার মেশিনে thread হয়তো খুব দ্রুত file পড়ে ফেলে, তাই সব ঠিক চলে। ভারী লোডের সার্ভারে thread একটু দেরিতে চালু হলো, আর সে পড়ল এমন মেমরি, যেখানে এখন অন্য কিছু আছে। detach এই বাগকে সবচেয়ে বেশি সাহায্য করে, কারণ detach করা thread কতক্ষণ বাঁচবে তা কেউ জানে না।

৪ · Data race — একই হাঁড়িতে দুজনের হাত

এবার সেই লবণের গল্প কোডে। দুটি thread একটি ভাগ করা counter-কে এক লাখ বার করে বাড়ায়। মোট হওয়ার কথা দুই লাখ। নিচের কোডটি ভুল — এটি চালানোর জন্য নয়, দেখার জন্য:

int counter = 0;                                   // ভাগ করা, বদলানো যায়

void add() { for (int i = 0; i < 100000; ++i) ++counter; }   // কোনো তালা নেই!

int main() {
    { std::jthread a(add), b(add); }               // দুজন একসাথে
    std::println("{}", counter);                   // 200000? কোনো নিশ্চয়তা নেই
}

বাস্তবে এটি কখনো 200000 দেখায়, কখনো 137452, কখনো অন্য কিছু — প্রতিবার আলাদা। কেন? কারণ ++counter দেখতে একটি কাজ, কিন্তু CPU-র কাছে তিনটি: মেমরি থেকে মান পড়া, এক যোগ করা, মেমরিতে ফেরত লেখা। একে বলে read-modify-write. দুই thread-এর এই তিন ধাপ মিশে গেলে কী হয়, ধাপে ধাপে দেখুন:

1T1: r1 = counter;      // পড়া2T2: r2 = counter;      // পড়া3T1: r1 = r1 + 1;       // যোগ4T2: r2 = r2 + 1;       // যোগ5T1: counter = r1;      // লেখা6T2: counter = r2;      // লেখা7// mutex থাকলে: T1-এর তিন ধাপ শেষ, তারপর T2

শুধু ভুল সংখ্যা নয় — undefined behavior

C++ standard এই পরিস্থিতির একটি নাম দিয়েছে: data race — দুটি thread একই মেমরি-স্থানে একসাথে হাত দেয়, অন্তত একটি লেখে, আর মাঝে কোনো সমন্বয় (mutex, atomic) নেই। standard বলে, data race থাকা প্রোগ্রামের আচরণ undefined behavior (পর্ব ৪৩)। অর্থাৎ “সংখ্যাটা একটু কম আসবে” — এটুকুও নিশ্চিত নয়। compiler ধরে নেয় আপনার প্রোগ্রামে data race নেই, আর সেই ভরসায় কোড সাজায়। যেমন, এক thread while (!done) {} লিখে অপেক্ষা করলে compiler done একবার পড়ে register-এ রেখে দিতে পারে — অন্য thread done = true করলেও লুপ আর কখনো শেষ হয় না।

ThreadSanitizer — race ধরার যন্ত্র

data race প্রায়ই পরীক্ষায় ধরা পড়ে না, কারণ বেশিরভাগ চালানোয় সময়ের হিসাব “ভাগ্যক্রমে” মিলে যায়। তাই চোখের ওপর ভরসা না করে যন্ত্র ব্যবহার করুন: ThreadSanitizer (পর্ব ৪৩-এ এর পরিচয় পেয়েছেন)। g++ -fsanitize=thread -g race.cpp দিয়ে বানিয়ে চালালে race হওয়ামাত্র এমন রিপোর্ট আসে (ঠিকানা আর সংখ্যা মেশিনভেদে আলাদা):

WARNING: ThreadSanitizer: data race (pid=4821)
  Write of size 4 at 0x55d0c2a4c014 by thread T2:
    #0 add() race.cpp:3
  Previous write of size 4 at 0x55d0c2a4c014 by thread T1:
    #0 add() race.cpp:3
  Location is global 'counter' of size 4 at 0x55d0c2a4c014
SUMMARY: ThreadSanitizer: data race race.cpp:3 in add()

রিপোর্টটি ঠিক বলে দেয় কোন ভ্যারিয়েবল (counter), কোন লাইন, কোন দুই thread. TSan শুধু সেই race ধরে, যা ওই চালানোয় সত্যিই ঘটেছে, তাই পরীক্ষার ইনপুট বাস্তবসম্মত হওয়া চাই। আর একটি জিনিস মনে রাখুন, data race একটি বিশেষ ধরনের race condition. race condition আরও বড় ধারণা: ফল নির্ভর করে কে আগে চলল তার ওপর। প্রতিটি কাজ আলাদা তালায় সুরক্ষিত হলেও যুক্তিতে race থাকতে পারে — যেমন “টিকিট বাকি আছে কি না দেখা” আর “টিকিট কাটা” দুটি আলাদা তালায় করলে, মাঝের ফাঁকে অন্যজন শেষ টিকিটটা নিয়ে নিতে পারে।

৫ · std::mutex — এক সময়ে একজন

সমাধান হলো একটি তালা: mutex (mutual exclusion). কোডের যে অংশ ভাগ করা ডেটায় হাত দেয় — যাকে বলে critical section — তার আগে তালা লাগান, পরে খোলেন। একজন তালা ধরে থাকলে অন্যরা অপেক্ষা করে।

হাতে m.lock() আর m.unlock() ডাকা যায়, কিন্তু তাতে আবার সেই পুরোনো ফাঁদ: মাঝে exception বা return হলে তালা চিরকাল লাগানো থাকে, আর বাকি সব thread চিরকাল লাইনে। তাই তালাও RAII দিয়ে নিন। standard library-তে তিনটি lock আছে:

একটি কাজের নিয়ম: mutex পাহারা দেয় ডেটা, কোড নয়। তাই mutex-কে তার ডেটার পাশেই রাখুন — একই class-এর সদস্য হিসেবে — আর কোন mutex কোন ভ্যারিয়েবল রক্ষা করে, তা মন্তব্যে লিখুন। ডেটা অনেক thread পড়ে কিন্তু কদাচিৎ লেখে (যেমন একটি দামের তালিকা), এমন ক্ষেত্রে C++17-এর std::shared_mutex অনেক পাঠককে একসাথে ঢুকতে দেয়, আর লেখককে একা।

বাস্তব উদাহরণ — কয়েকটি ভোটকেন্দ্রের ভোট একসাথে গোনা

একটি নির্বাচনী এলাকায় তিনটি ভোটকেন্দ্র। প্রতিটি কেন্দ্রের বুথগুলোর ভোট আলাদা thread গুনবে, তারপর এলাকার মোট হবে। এখানে দুটি কৌশল একসাথে দেখুন: প্রতিটি thread নিজের কেন্দ্রের ফল লেখে নিজের আলাদা ঘরে (কোনো ভাগাভাগি নেই, তাই তালাও লাগে না), আর এলাকার মোট — যা সবাই বদলায় — বাড়ানো হয় তালা দিয়ে। প্রিন্ট হয় শুধু সব thread শেষ হওয়ার পরে:

#include <mutex>
#include <numeric>
#include <print>
#include <thread>
#include <vector>
int main() {
    std::vector<std::vector<int>> centers{{120, 85, 40}, {200, 15}, {75, 75, 75, 30}};
    std::vector<long> part(centers.size());   // one slot per thread: no sharing
    long total = 0;                           // shared by all: guarded by m
    std::mutex m;
    {
        std::vector<std::jthread> workers;
        for (std::size_t i = 0; i < centers.size(); ++i)
            workers.emplace_back([&, i] {
                part[i] = std::accumulate(centers[i].begin(), centers[i].end(), 0L);
                std::scoped_lock lock(m);     // short critical section
                total += part[i];
            });
    }                                         // every jthread joins here
    for (std::size_t i = 0; i < part.size(); ++i) std::println("center {}: {}", i + 1, part[i]);
    std::println("total: {}", total);
}

খেয়াল করুন, আলাদা ঘরের কৌশলটিই আসল জয়। thread যত বেশি তালার জন্য অপেক্ষা করে, তত বেশি তারা আসলে একজন একজন করে চলে। তালা কম লাগলে ভালো; একেবারে না লাগলে সবচেয়ে ভালো। (আলাদা ঘর হলেও ঘরগুলো একই cache line-এ পড়লে core-রা লাইনটি নিয়ে টানাটানি করে — একে বলে false sharing; ফল ভুল হয় না, শুধু গতি কমে। পর্ব ৪৯-এ মাপবেন।)

৬ · Deadlock — দুজনেই অপেক্ষায়, কেউ এগোয় না

তালা সমস্যার সমাধান করে, কিন্তু নতুন একটি সমস্যা আনে। একটি মোবাইল ব্যাংকিং সার্ভারে টাকা পাঠানোর ফাংশন ভাবুন। দুটি অ্যাকাউন্টের ব্যালান্সই বদলাবে, তাই দুটিরই তালা লাগে। একই মুহূর্তে রহিম করিমকে ৫০০ টাকা পাঠালেন, আর করিম রহিমকে ৩০০. দুটি thread, দুটি তালা, উল্টো ক্রমে:

1void transfer(Account& from, Account& to, int taka) {2    std::lock_guard a(from.m);      // প্রথম তালা3    std::lock_guard b(to.m);        // দ্বিতীয় তালা4    from.balance -= taka;  to.balance += taka;5}6// T1: transfer(rahim, karim, 500)   T2: transfer(karim, rahim, 300)7std::scoped_lock both(from.m, to.m);  // লাইন ২-৩-এর বদলে

দার্শনিকদের খাবার টেবিল

এই সমস্যার সবচেয়ে বিখ্যাত রূপ dining philosophers. গোল টেবিলে পাঁচজন দার্শনিক, প্রতি দুজনের মাঝে একটি করে কাঁটাচামচ — মোট পাঁচটি। খেতে দুটি লাগে। সবাই একসাথে বাঁ পাশের কাঁটা তুলে নিলে, ডান পাশেরটা কারও হাতেই খালি থাকে না — সবাই ক্ষুধার্ত বসে থাকেন। Edsger Dijkstra ১৯৬৫ সালের দিকে এমন একটি সমস্যা ছাত্রদের পরীক্ষায় দিয়েছিলেন, আর পরে Tony Hoare একে দার্শনিকদের গল্পে রূপ দেন। ১৯৭১ সালে Coffman ও সহকর্মীরা দেখান, deadlock-এর জন্য চারটি শর্ত একসাথে লাগে: (১) জিনিসটি একজনই ধরতে পারে, (২) একটি ধরে অন্যটির অপেক্ষা, (৩) কেউ জোর করে কেড়ে নিতে পারে না, (৪) অপেক্ষার একটি চক্র। যেকোনো একটি ভাঙলেই deadlock অসম্ভব।

একটি সতর্কতা: একই thread একই std::mutex দুবার লক করলে (যেমন তালা ধরা ফাংশন থেকে আরেকটি ফাংশন ডাকল, যে একই তালা নেয়) তা-ও undefined behavior, বাস্তবে সাধারণত নিজের সাথেই deadlock. প্রোগ্রাম ঝুলে গেলে debugger দিয়ে সব thread-এর অবস্থা দেখুন — দুটি thread lock-এর ভেতরে আটকে থাকলেই বুঝবেন (পর্ব ৪৮-এ debugger).

৭ · condition_variable — অপেক্ষার সঠিক উপায়

রেস্টুরেন্টে ওয়েটার অর্ডার নিয়ে রান্নাঘরের অর্ডার-বোর্ডে লাগান, আর বাবুর্চিরা সেখান থেকে একটি করে নিয়ে রাঁধেন। এই নকশার নাম producer–consumer: কেউ কাজ বানায় (producer), কেউ করে (consumer), মাঝে একটি ভাগ করা std::queue. queue-তে push আর pop দুটিই mutex দিয়ে পাহারা দেবেন, সেটা এখন জানা। প্রশ্ন হলো: বোর্ড খালি থাকলে বাবুর্চি কী করবেন?

std::condition_variable (<condition_variable>) তিনটি জিনিস একসাথে চালায়: একটি mutex, একটি শর্ত (“queue খালি নয়”), আর একটি ঘণ্টা। consumer লেখে cv.wait(lock, শর্ত); producer ডেটা বদলে বাজায় notify_one() (একজনকে জাগাও) বা notify_all() (সবাইকে)। কেন wait-এর সাথে unique_lock লাগে? কারণ ঘুমানোর মুহূর্তে wait-কে তালা ছেড়ে দিতে হয় (নইলে producer কখনো push করতে পারত না), আর জেগে উঠে আবার নিতে হয়। lock_guard মাঝপথে ছাড়তে পারে না; unique_lock পারে। হাতবদলটা ধাপে ধাপে দেখুন:

1// বাবুর্চি (consumer)2std::unique_lock lock(m);3cv.wait(lock, [] { return !orders.empty(); });4int o = orders.front(); orders.pop();5// ওয়েটার (producer)6{ std::lock_guard g(m); orders.push(42); }7cv.notify_one();

শর্তের দ্বিতীয় কাজও আছে: notify যদি wait-এর আগেই বেজে যায় (ওয়েটার আগে এলেন, বাবুর্চি পরে), শর্ত-ছাড়া wait সেই ঘণ্টা আর কখনো শোনে না — চিরকাল ঘুম, একে বলে lost wakeup. শর্তসহ wait প্রথমেই দেখে queue খালি কি না, তাই ঘুমাতেই যায় না। নিয়ম তাই সরল: wait সবসময় শর্তসহ।

বাস্তব উদাহরণ — রেস্টুরেন্টের অর্ডার queue আর দুজন বাবুর্চি

একজন ওয়েটার পাঁচটি অর্ডার (দাম টাকায়) আনেন, দুজন বাবুর্চি নেন। রান্নাঘর বন্ধের সংকেত হলো দাম 0-এর একটি “বন্ধ” চিরকুট — প্রতিটি বাবুর্চির জন্য একটি। শেষে শুধু সারাংশ প্রিন্ট হয়, thread-রা নিজেরা কিছু প্রিন্ট করে না, তাই আউটপুট নির্দিষ্ট:

#include <condition_variable>
#include <mutex>
#include <print>
#include <queue>
#include <thread>
std::queue<int> orders;  std::mutex m;  std::condition_variable cv;
int cooked = 0, bill = 0;                              // guarded by m
void cook() {
    while (true) {
        std::unique_lock lock(m);
        cv.wait(lock, [] { return !orders.empty(); }); // always with a predicate
        int price = orders.front(); orders.pop();
        if (price == 0) return;                        // 0 = "kitchen closed" slip
        ++cooked; bill += price;
    }
}
int main() {
    {   std::jthread a(cook), b(cook);                 // two cooks start waiting
        for (int p : {120, 80, 250, 60, 90, 0, 0}) {   // one closing slip per cook
            { std::lock_guard g(m); orders.push(p); }
            cv.notify_one();
        }
    }                                                  // a and b join here
    std::println("cooked {} orders, bill {} taka", cooked, bill);
}

৮ · stop_token — ভদ্রভাবে থামতে বলা

একটি অ্যাপ বড় একটি ফাইল ডাউনলোড করছে, আর ব্যবহারকারী “Cancel” চাপলেন। thread-টিকে এখনই মেরে ফেলা যায় না কেন? কারণ সে হয়তো এই মুহূর্তে একটি mutex ধরে আছে (মরলে তালা চিরকাল লাগানো), বা ফাইলে অর্ধেক লিখেছে, বা মেমরি নিয়েছে যা ফেরত যাবে না। C++-এ তাই অন্য thread-কে জোর করে মারার কোনো standard উপায়ই নেই। পথ একটাই — cooperative cancellation: থামার অনুরোধ পাঠানো, আর thread নিজে সুবিধাজনক জায়গায় সেটা দেখে, পরিষ্কার করে, ফিরে যায়।

C++20-এর আগে এর জন্য নিজে একটি std::atomic<bool> flag বানাতে হতো। jthread এটা তৈরি অবস্থায় দেয়: thread-এর ফাংশনের প্রথম প্যারামিটার যদি std::stop_token হয়, jthread নিজে থেকে সেটি পাঠায়। বাইরে থেকে request_stop() ডাকলে ভেতরে stop_requested() সত্য হয়। আর jthread-এর destructor join-এর আগে নিজেই request_stop() ডাকে।

1std::jthread dl([](std::stop_token st) {2    for (int part = 1; part <= 10; ++part) {3        if (st.stop_requested()) { removePartial(); return; }4        download(part);5    }6});7// ব্যবহারকারী Cancel চাপলেন:8dl.request_stop();9// scope শেষ → dl-এর destructor: request_stop() + join()

অনুরোধ আসামাত্র কিছু করতে চাইলে std::stop_callback দিয়ে একটি ফাংশন নিবন্ধন করা যায়। আর thread যদি condition_variable-এ ঘুমিয়ে থাকে? সাধারণ condition_variable stop_token চেনে না; C++20-এর std::condition_variable_any-এর wait-এ token দেওয়া যায়, তখন থামার অনুরোধেও ঘুম ভাঙে।

৯ · নিরাপদ নকশা — কম ভাগাভাগি, latch, barrier আর কতগুলো thread

অভিজ্ঞ প্রোগ্রামারদের আসল দক্ষতা তালা লাগানোয় নয় — তালার দরকারই না রাখায়। অংশ ১-এর তিন শর্ত মনে করুন: ভাগ করা, বদলানো যায়, একই সময়ে। ভালো নকশা শুরু থেকেই এর একটি সরিয়ে দেয়:

শেষ দুটি আসলে একই ধারণার দুই রূপ: thread pool মানে producer–consumer queue, যার consumer-রা স্থায়ী কর্মী। C++23 পর্যন্ত standard library-তে তৈরি thread pool নেই, তাই প্রজেক্টে সাধারণত একটি পরীক্ষিত লাইব্রেরি ব্যবহার করা হয়, বা পর্ব ৪৬-এর std::async-এর মতো উঁচু স্তরের যন্ত্র।

কতগুলো thread বানাবেন?

কাজ যদি CPU-নির্ভর হয় (হিসাব, ছবি প্রসেসিং), তাহলে core-এর সংখ্যার চেয়ে বেশি thread বানালে লাভ নেই — বাড়তি thread শুধু পালার জন্য অপেক্ষা করে আর context switch বাড়ায়। শুরুর অনুমান হিসেবে std::thread::hardware_concurrency() নিন, কিন্তু 0 ফেরত এলে একটি যুক্তিসংগত ডিফল্ট রাখুন। কাজ যদি অপেক্ষা-নির্ভর হয় (নেটওয়ার্ক, ডিস্ক), core-এর চেয়ে বেশি thread চলতে পারে, কারণ বেশিরভাগ সময় তারা ঘুমিয়ে থাকে। আর গতি-বৃদ্ধির একটি কঠিন সীমা আছে, যাকে বলে Amdahl's law: প্রোগ্রামের যে অংশ ক্রমিক (তালার ভেতরের অংশও!), সেটাই শেষ কথা বলে (ভাবনার প্রশ্ন ২)। সবশেষে মেপে দেখুন — অনুমানে নয় (পর্ব ৪৯)।

Latch আর barrier — সবাই পৌঁছানো পর্যন্ত অপেক্ষা (C++20)

কখনো শুধু এটুকু দরকার: “সবাই কাজ শেষ করলে তবেই এগোব।” এর জন্য condition_variable দিয়ে পুরো ব্যবস্থা না বানিয়ে C++20-এর দুটি সরল যন্ত্র ব্যবহার করুন। std::latch একবারের গণক: তিনটি কেন্দ্রের ফল আসা পর্যন্ত রিটার্নিং অফিসার অপেক্ষা করবেন, তারপর ঘোষণা।

#include <latch>
std::latch reported(3);              // তিনটি কেন্দ্র
// প্রতিটি কেন্দ্রের thread, গোনা শেষে:
reported.count_down();               // গণক এক কমল
// রিটার্নিং অফিসার (main):
reported.wait();                     // গণক 0 না হওয়া পর্যন্ত অপেক্ষা, তারপর ঘোষণা

latch শূন্যে পৌঁছালে আর ফিরিয়ে দেওয়া যায় না। বারবার ধাপে ধাপে মিলতে হলে std::barrier: ক্রিকেট দলের অনুশীলনে সবাই প্রথম ড্রিল শেষ না করা পর্যন্ত কেউ দ্বিতীয়টি শুরু করেন না, আর প্রতি ধাপের শেষে গণক নিজে থেকে আবার শুরু হয়। চাইলে প্রতি ধাপ শেষে একবার চলা একটি ফাংশনও দেওয়া যায় — যেমন সিমুলেশনের প্রতিটি ধাপের ফল একসাথে করা।

আর একটি ছোট কথা: শুধু একটি সংখ্যা বাড়ানোর জন্য পুরো mutex অনেক সময় বেশি ভারী — তার জন্য আছে std::atomic, যার ++ নিজেই অবিভাজ্য। এর পুরো গল্প, সাথে memory model, পরের পর্বে।

১০ · AI-এর যুগে — thread-কোডের ভুল ধরা

thread-এর বাগ AI-এর জন্য সবচেয়ে কঠিন জায়গাগুলোর একটি, কারণ ভুল কোডও প্রায়ই compile হয় আর দশবারের নয়বার ঠিক উত্তর দেয়। অনলাইনের অসংখ্য উদাহরণে sleep দিয়ে “সমন্বয়”, শর্ত-ছাড়া wait, বা পুরোনো std::thread আর detach — AI সেগুলোই শিখেছে। আপনার কাজ হলো কোড চালিয়ে নয়, পড়ে যাচাই করা:

AI-এর thread-কোড যাচাইয়ের চেকলিস্ট

• প্রতিটি thread কোথায় join হয়, আঙুল দিয়ে দেখাতে পারি (jthread হলে কোন scope শেষে)
• thread-এ পাঠানো প্রতিটি reference বা [&] capture-এর জন্য নিশ্চিত: ভ্যারিয়েবলটি thread-এর চেয়ে বেশি বাঁচে
• প্রতিটি ভাগ করা, বদলানো যায় এমন ভ্যারিয়েবলের একটি নির্দিষ্ট mutex আছে, আর তার সব পড়া-লেখা সেই তালার ভেতরে
• কোথাও দুটি তালা একসাথে লাগলে scoped_lock, বা পুরো কোডে একটি নির্দিষ্ট ক্রম
• প্রতিটি wait-এ শর্ত আছে, আর প্রতিটি অপেক্ষারত thread-কে শেষে জাগানোর বা থামানোর ব্যবস্থা আছে
• sleep_for শুধু আসল বিরতির জন্য, সমন্বয়ের জন্য নয়; volatile নেই
• -fsanitize=thread দিয়ে বানিয়ে বাস্তবসম্মত ইনপুটে কয়েকবার চালিয়েছি — কোনো রিপোর্ট নেই