async, future আর atomics — পেছনে কাজ, পরে ফল

১ · কর্মী নয়, ফল চাই — task-ভিত্তিক চিন্তা

আগের পর্বে আপনি std::thread দিয়ে নতুন thread চালিয়েছেন, join করেছেন, আর ভাগ করা ডেটা mutex দিয়ে পাহারা দিয়েছেন। সেখানে আপনি ছিলেন একজন ম্যানেজার: কর্মী নিয়োগ করা, তাকে কাজ বুঝিয়ে দেওয়া, শেষে তার জন্য অপেক্ষা করা, আর কাজের ফল কোথায় রাখবে তা আগে থেকে ঠিক করে দেওয়া। একটা সমস্যাও দেখেছেন: std::thread কোনো মান ফেরত দেয় না। ফল চাইলে একটি ভাগ করা ভ্যারিয়েবল বানাতে হয়, তাকে mutex দিয়ে ঘিরতে হয়, আর join-এর পরে সেটা পড়তে হয়।

কিন্তু অনেক সময় আপনি কর্মী সামলাতে চান না। আপনি শুধু বলতে চান: “এই হিসাবটা পেছনে করে রাখো, আমি পরে উত্তর নিয়ে যাব।” কে করবে, কোন thread-এ করবে, ফল কোথায় রাখবে — এসব নিয়ে মাথা ঘামাতে চান না। এই চিন্তাকে বলে task-ভিত্তিক প্রোগ্রামিং: আপনি ভাবেন কাজ আর তার ফল নিয়ে, কর্মী নিয়ে নয়।

এই পর্বের দ্বিতীয় ভাগ আরও নিচের স্তরে। একটি website-এর hit counter ভাবুন: হাজারো request একসাথে এসে শুধু একটি সংখ্যা এক করে বাড়াতে চায়। এর জন্য পুরো mutex লাগানো অনেকটা একটি টাকা জমা দিতে ব্যাংকের পুরো শাখা বন্ধ করার মতো। CPU-তে কিছু ছোট নির্দেশ আছে, যা মাঝপথে কেউ ভাঙতে পারে না — পড়া, বদলানো আর লেখা এক ধাক্কায় হয়। C++ এগুলো দেয় std::atomic নামে। এগুলো দিয়ে তালা ছাড়াই নিরাপদ counter বানানো যায়, আর এক thread থেকে আরেক thread-কে “ডেটা তৈরি” সংকেত দেওয়া যায়।

২ · std::async আর std::future — পেছনে হিসাব, পরে উত্তর

একটি ভ্রমণ অ্যাপ ভাবুন। স্ক্রিন খোলার সময় তাকে ডলারের বিনিময় হার আর আবহাওয়ার পূর্বাভাস — দুটোই আনতে হয়। আসল অ্যাপে এগুলো নেটওয়ার্ক থেকে আসত; আমরা ধরে নিই এগুলো সময়সাপেক্ষ হিসাব। পুরোনো পথে একটির পর একটি হিসাব করলে দুটির সময় যোগ হয়। <future> header-এর std::async দিয়ে দুটোই একসাথে পেছনে শুরু করা যায়:

#include <future>

double fetchRate();        // সময়সাপেক্ষ হিসাব (উদাহরণ)
int    fetchWeather();

auto rate    = std::async(std::launch::async, fetchRate);     // রসিদ ১
auto weather = std::async(std::launch::async, fetchWeather);  // রসিদ ২
drawScreen();                                // এর মধ্যে নিজের কাজ
std::println("USD {} | {} C", rate.get(), weather.get());

std::async একটি ফাংশন (বা lambda) আর তার argument নেয়, কাজটা চালানোর ব্যবস্থা করে, আর সাথে সাথে ফেরত দেয় একটি std::future<T> — যেখানে T হলো ফাংশনের return টাইপ। future আর পেছনের কাজের মাঝে একটি লুকানো জায়গা থাকে, যার নাম shared state. কাজ শেষ হলে ফল (বা exception) সেখানে রাখা হয়; future সেখান থেকে তুলে আনে। এ জন্যই কোনো ভাগ করা ভ্যারিয়েবল বা mutex আপনাকে লিখতে হয়নি।

Launch policy — কখন, কোথায় চলবে

প্রথম argument-টি হলো launch policy. এখানে সতর্কভাবে পড়ুন, কারণ অনেক বই ও AI এটি ভুল বলে:

তৃতীয় সারিটিই ফাঁদ। policy না দিলে কাজটি deferred হতেই পারে — তখন সেটা আদৌ পেছনে চলে না, আপনি get() ডাকলে আপনার নিজের thread-এই চলে। বাস্তবে অনেক লাইব্রেরি সুযোগ থাকলে নতুন thread নেয়, কিন্তু standard তা বাধ্য করে না। তাই নিয়ম সহজ: সমান্তরালে চলা দরকার হলে সবসময় std::launch::async লিখুন।

get(), wait() আর wait_for()

• get() — ফল তৈরি না হওয়া পর্যন্ত ডাকার thread-কে আটকে রাখে (block), তারপর ফল ফেরত দেয়। একবারই ডাকা যায়। ডাকার পর future-এর valid() হয়ে যায় false; আবার get() ডাকা undefined behavior (অনেক লাইব্রেরি তখন std::future_error ছোড়ে, কিন্তু তার ওপর ভরসা করবেন না)। কারণ get() ফলটি move করে বের করে আনে — রসিদ জমা দিলে পাঞ্জাবি আপনার, রসিদ আর থাকে না।
• wait() — শুধু অপেক্ষা করে, ফল তোলে না। পরে get() ডাকা যায়।
• wait_for(সময়) — বড়জোর ততক্ষণ অপেক্ষা করে, তারপর অবস্থা জানায়: ready (তৈরি), timeout (এখনো হয়নি) বা deferred (কাজটি deferred, এখনো শুরুই হয়নি)। এতে UI thread আটকে না থেকে মাঝে মাঝে খোঁজ নিতে পারে: “তৈরি হলে দেখাও, না হলে ঘুরন্ত চিহ্ন দেখাতে থাকো।”

পুরো জীবনচক্রটা ধাপে ধাপে দেখুন — শেষ ধাপে exception-এর পথও আছে। প্রতিটি ধাপে আগে নিজে অনুমান করুন, তারপর “পরে” চাপুন:

1double fetchRate() { /* হিসাব */ return 117.5; }2auto f = std::async(std::launch::async, fetchRate);3drawScreen();               // main নিজের কাজ করছে4double usd = f.get();       // ফল না আসা পর্যন্ত অপেক্ষা5std::println("USD = {}", usd);6// fetchRate() throw করলে → get() সেটাই আবার ছোড়ে

শেষ ধাপটি বিশেষ গুরুত্বপূর্ণ। পর্ব ৪৫-এ দেখেছেন, একটি সাধারণ std::thread-এর ফাংশন থেকে exception বেরিয়ে গেলে সাথে সাথে std::terminate — পুরো প্রোগ্রাম বন্ধ। future সেই ভুলকে একটি সাধারণ C++ exception-এ রূপ দেয়, যা পর্ব ৩৭-এর মতোই catch করা যায়। ভেতরে লাইব্রেরি এটা করে std::exception_ptr দিয়ে — একটি exception-কে এক thread থেকে ধরে আরেক thread-এ নিয়ে যাওয়ার পাত্র।

using namespace std::chrono_literals;
while (rate.wait_for(100ms) != std::future_status::ready)
    showSpinner();                 // প্রতি ১০০ ms-এ একবার ঘুরন্ত চিহ্ন
double r = rate.get();

৩ · ফেলে দেওয়া future-এর ফাঁদ — destructor-এ অপেক্ষা

এখন সেই আচরণটি, যা অভিজ্ঞ প্রোগ্রামারদেরও অবাক করে। একটি অনলাইন দোকানে অর্ডার হলে দুটি কাজ “পেছনে” করতে চান: log ফাইলে লেখা আর গ্রাহককে email পাঠানো। ফল দরকার নেই, তাই কেউ লেখেন:

std::async(std::launch::async, saveLog);     // future রাখা হলো না
std::async(std::launch::async, sendEmail);   // ভাবছেন দুটো একসাথে চলবে...

দেখতে নিরীহ। কিন্তু নিয়মটি হলো: std::async থেকে পাওয়া future-এর destructor, কাজটি শেষ না হওয়া পর্যন্ত অপেক্ষা করে (যদি সেটিই ওই shared state-এর শেষ রসিদ হয়)। আপনি future কোনো নামে রাখেননি, তাই সেটি একটি temporary — লাইনের শেষ ;-এ পৌঁছালেই ধ্বংস হয়। ধ্বংসের সময় সে অপেক্ষা করে। ফলে দ্বিতীয় লাইন শুরুই হয় প্রথম কাজ শেষ হওয়ার পর। ধাপে ধাপে দেখুন:

সময় →  0s    1s    2s    3s    4s
main : [async]?
w1   : [saveLog █████]
future-এর নাম নেই — ; পর্যন্তই আয়ু

সময় →  0s    1s    2s    3s    4s
main : [~~ অপেক্ষা ~~]
w1   : [saveLog █████]
main পরের লাইনে যেতেই পারছে না

সময় →  0s    1s    2s    3s    4s
main : [~~~~~~~~~~~~][~~~~~~~~~~~]
w1   : [saveLog ████]
w2   :              [sendEmail ██]
মোট ≈ 4s — thread দুটি, কাজ ক্রমিক!

সময় →  0s    1s    2s    3s    4s
main : [f1][f2] অন্য কাজ, তারপর get()
w1   : [saveLog ████]
w2   : [sendEmail ██]
মোট ≈ 2s — দুটো সত্যিই একসাথে

async-এর future    → অপেক্ষা করে
promise-এর future  → করে না
packaged_task-এর   → করে না
“fire and forget” async দিয়ে হয় না

৪ · ভাগ করে যোগ — চার টুকরোয় বিক্রির হিসাব

একটি সুপারশপ চেইনের দশ লাখ বিক্রির রেকর্ড আছে, মোট টাকা বের করতে হবে। একজন হিসাবরক্ষক পুরো খাতা যোগ করলে যে সময় লাগে, চারজন চার ভাগ করে যোগ করে শেষে চারটি সংখ্যা মেলালে তার প্রায় চার ভাগের এক ভাগ সময় লাগে (যদি CPU-তে অন্তত চারটি core থাকে)। async দিয়ে এই নকশা খুব পরিষ্কারভাবে লেখা যায় — প্রতিটি টুকরোর জন্য একটি রসিদ, শেষে রসিদগুলো ভাঙানো। একই প্রোগ্রামে exception-এর পথও আছে:

#include <future>
#include <numeric>
#include <print>
#include <stdexcept>
#include <vector>
long long sumPart(const std::vector<int>& v, std::size_t from, std::size_t to) {
    return std::accumulate(v.begin() + from, v.begin() + to, 0LL);
}
int main() {
    std::vector<int> sales(1'000'000);
    for (std::size_t i = 0; i < sales.size(); ++i) sales[i] = i % 100 + 1;
    const std::size_t step = sales.size() / 4;
    std::vector<std::future<long long>> parts;
    for (std::size_t i = 0; i < 4; ++i)
        parts.push_back(std::async(std::launch::async, sumPart, std::cref(sales), i * step, (i + 1) * step));
    long long total = 0;
    for (auto& f : parts) total += f.get();      // wait for each part
    std::println("total sales = {}", total);
    auto rate = std::async(std::launch::async, []() -> double { throw std::runtime_error("rate server down"); });
    try { std::println("rate = {}", rate.get()); }
    catch (const std::exception& e) { std::println("caught: {}", e.what()); }
}

এই নকশার নাম “ভাগ করো, আলাদা হিসাব করো, শেষে মেলাও” — fork-join. দুটি বাস্তব সতর্কতা মনে রাখুন। প্রথমত, প্রতিটি টুকরো যথেষ্ট বড় হওয়া চাই। একটি thread চালু করতে কয়েক মাইক্রোসেকেন্ড লাগে; একশোটি সংখ্যা যোগের জন্য নতুন thread খোলা মানে এক কাপ চায়ের জন্য পুরো রান্নাঘর জ্বালানো। দ্বিতীয়ত, core-এর চেয়ে বেশি টুকরো করলে লাভ বাড়ে না। std::thread::hardware_concurrency() একটি ইঙ্গিত দেয়, কতগুলো thread আসলে একসাথে চলতে পারে (এটি ০-ও ফেরত দিতে পারে, যদি জানা না যায়)। আর এই যোগের কাজটি আসলে লাইব্রেরি নিজেই করে দিতে পারে — অনুচ্ছেদ ৮-এ std::reduce দেখবেন।

৫ · promise, packaged_task আর shared_future — হাতে হাতে হস্তান্তর

std::async সুবিধাজনক, কারণ রসিদ আর কাজ একসাথে বানায়। কিন্তু কখনো ফল তৈরি হয় এমন জায়গায়, যা “একটি ফাংশনের return value” নয় — যেমন একটি দীর্ঘজীবী thread কাজের মাঝপথে একটি মান জানায়, অথবা ফলটি আসে একটি callback থেকে। তখন রসিদের দুই প্রান্ত আলাদা করে হাতে নিতে হয়।

std::promise — লেখার প্রান্ত

std::promise<T> হলো সেই প্রতিশ্রুতি, যে “একদিন একটি T দেব”। তার কাছ থেকে get_future() দিয়ে একটি future নেওয়া যায় — পড়ার প্রান্ত। যে thread ফল বানায়, সে set_value(v) ডাকে (বা ভুল হলে set_exception). দুই প্রান্তের মাঝে সেই একই shared state:

std::promise<std::string> p;
std::future<std::string>  f = p.get_future();     // পড়ার প্রান্ত

std::jthread loader([&p] {
    std::string cfg = readConfigFile();             // ধীর কাজ
    p.set_value(std::move(cfg));                    // ফল পাঠানো — f এখন ready
    keepWatchingForChanges();                       // thread চলতেই থাকে
});
std::println("config: {}", f.get());                // ready হলেই পাবেন

এখানে loader thread ফল পাঠানোর পরেও কাজ চালিয়ে যায় — std::async দিয়ে এটা প্রকাশ করা যেত না, কারণ async-এর ফল আসে কেবল ফাংশন শেষ হলে। দুটি নিয়ম মনে রাখুন। set_value একবারই ডাকা যায় (দ্বিতীয়বার std::future_error). আর promise যদি কোনো মান না দিয়েই ধ্বংস হয়, তবে future-এর get() একটি std::future_error ছোড়ে, যার কারণ broken_promise — দর্জি দোকান বন্ধ করে চলে গেছেন, রসিদ এখন অচল। অপেক্ষাকারী তাই চিরকাল আটকে থাকে না।

std::packaged_task — কাজ আর রসিদ একসাথে মোড়ানো (এক ঝলক)

std::packaged_task একটি ফাংশনকে মুড়ে দেয়, যাতে সেটি ডাকা হলে return value নিজে থেকেই একটি promise-এ যায়। পার্থক্য হলো, কখন আর কোথায় ডাকা হবে, তা আপনি ঠিক করেন — যেমন একটি কাজের সারিতে (queue) রেখে দিয়ে, যা পরে কোনো worker thread তুলে নিয়ে চালাবে। thread pool-গুলো ঠিক এভাবেই ভেতরে future ফেরত দেয়।

std::packaged_task<int(int)> task([](int x) { return x * x; });
std::future<int> f = task.get_future();
jobQueue.push(std::move(task));     // পরে কোনো worker ডাকবে: task(12)
// ... f.get() == 144

std::shared_future — এক ফল, অনেক পাঠক

সাধারণ future-এর ফল একজনই তুলতে পারে, আর future নিজে কপি করা যায় না (শুধু move). কিন্তু ধরুন একটি অ্যাপের পাঁচটি অংশ — মেনু, ছবি, ভাষা, থিম, নোটিফিকেশন — সবাই একই কনফিগারেশনের জন্য অপেক্ষা করছে। এর জন্য std::shared_future: f.share() দিয়ে বানানো যায়, কপি করা যায়, আর প্রতিটি কপি যতবার খুশি get() ডাকতে পারে — ফল ফেরত আসে const reference হিসেবে। নিয়ম একটাই: প্রতিটি thread নিজের কপি রাখবে; একই shared_future object-কে একাধিক thread থেকে একসাথে ছোঁয়া নিরাপদ নয়, কিন্তু আলাদা কপি একই shared state পড়তে পারে।

std::shared_future<Config> cfg = p.get_future().share();
auto widget = [cfg](std::string name) {        // প্রত্যেকে নিজের কপি নেয়
    const Config& c = cfg.get();               // সবাই একই ফল পায়
    draw(name, c.theme);
};

শেষ সারিটি মনে রাখুন: future একবারের হস্তান্তর — একটি রসিদ, একটি পাঞ্জাবি। বারবার ঘটা ঘটনার জন্য এটি নয়।

৬ · std::atomic — ভাঙা যায় না এমন ছোট কাজ

পর্ব ৪৫-এ দেখেছেন, দুটি thread একসাথে hits++ করলে গোনা হারায়। কারণ ++ আসলে তিনটি ধাপ — মেমরি থেকে পড়া, এক যোগ করা, ফিরিয়ে লেখা — আর দুই thread-এর ধাপগুলো মিশে যেতে পারে। এটি একটি data race, আর C++-এ সেটি undefined behavior. mutex দিয়ে সমাধান হয়, কিন্তু শুধু একটি সংখ্যা বাড়াতে পুরো তালা অনেক সময় বাড়াবাড়ি।

std::atomic<T> (<atomic> header) একটি ভ্যারিয়েবলকে এমন বানায়, যার ওপর প্রতিটি কাজ একটি atomic operation — অন্য কোনো thread মাঝপথ দেখতে পায় না; হয় পুরো কাজটা হয়েছে, নয়তো একটুও হয়নি। বিকাশ বা নগদ অ্যাকাউন্টের ব্যালান্সের কথা ভাবুন: দুজন একই মুহূর্তে টাকা পাঠালে সিস্টেম কখনো “অর্ধেক যোগ” অবস্থা দেখায় না। সাধারণ x86 বা ARM CPU-তে এগুলো সাধারণত একটি বিশেষ CPU নির্দেশ দিয়েই হয়ে যায়, তালা ছাড়া।

শেষ সারিটির নাম CAS (compare-and-swap), আর এটি সব lock-free কৌশলের মেরুদণ্ড। কেন দরকার? “সবচেয়ে ধীর response time” রাখতে চাই — প্রতিটি request নিজের সময় দেখে, বড় হলে সর্বোচ্চ মানটি বদলায়। C++23 পর্যন্ত fetch_add-এর মতো কোনো তৈরি fetch_max নেই (নতুন standard-এ যোগ হচ্ছে), তাই “পড়ো, তুলনা করো, লেখো” — এই তিন ধাপকে নিরাপদ করতে হয় CAS লুপ দিয়ে। নিচের প্রোগ্রামে চারটি thread একটি website-এর hit counter বাড়ায় আর একই সাথে সবচেয়ে ধীর response time আপডেট করে:

#include <atomic>
#include <print>
#include <thread>
#include <vector>
std::atomic<long> hits{0};          // website hit counter
std::atomic<int> slowest{0};        // slowest response time in ms
void updateMax(int ms) {
    int cur = slowest.load();
    while (cur < ms && !slowest.compare_exchange_weak(cur, ms)) { }  // fail: cur = newer value, retry
}
int main() {
    {   std::vector<std::jthread> workers;
        for (int t = 0; t < 4; ++t)
            workers.emplace_back([t] {
                for (int i = 0; i < 100'000; ++i) {
                    hits.fetch_add(1, std::memory_order_relaxed);
                    updateMax((i * 7 + t * 13) % 997);
                }
            });
    }                                   // every jthread joins here
    std::println("hits = {}, slowest = {} ms, lock-free: {}", hits.load(), slowest.load(), hits.is_lock_free());
}

updateMax-এর লুপটি প্রথমবার দেখলে অদ্ভুত লাগে। দুটি thread একই মুহূর্তে আলাদা মান নিয়ে এলে কী ঘটে, ধাপে ধাপে দেখুন:

1int cur = slowest.load();2while (cur < ms &&3       !slowest.compare_exchange_weak(cur, ms)) { }4// ভুল পথ: if (slowest < ms) slowest = ms;

atomic না mutex?

সবচেয়ে বড় শিক্ষা দ্বিতীয় সারিতে। দুটি আলাদা atomic — balance আর txCount — প্রত্যেকটি নিজে নিরাপদ, কিন্তু “দুটো একসাথে বদলাও” নিরাপদ নয়: মাঝখানে অন্য thread একটি বদলানো আর একটি পুরোনো মান দেখতে পারে। একাধিক ভ্যারিয়েবলের মধ্যে কোনো নিয়ম (invariant) রাখতে হলে mutex নিন। আর atomic-ও বিনামূল্যে নয়: অনেক core একই atomic-এ বারবার লিখলে সেই cache line core থেকে core-এ ছোটাছুটি করে। দুটি আলাদা atomic একই cache line-এ পড়লেও একই সমস্যা হয় — একে বলে false sharing.

আরও কিছু atomic যন্ত্র

• lock-free আর is_lock_free(): std::atomic<T> যেকোনো trivially copyable টাইপে বানানো যায়, কিন্তু বড় টাইপের জন্য লাইব্রেরি ভেতরে গোপনে একটি তালা ব্যবহার করতে পারে। is_lock_free() চলার সময় জানায়, আর is_always_lock_free (C++17) compile-এর সময়েই।
• std::atomic_flag: সবচেয়ে সরল atomic — শুধু একটি বুলিয়ান পতাকা। standard একমাত্র এটিকেই সব প্ল্যাটফর্মে lock-free হওয়ার নিশ্চয়তা দেয়। test_and_set() আর clear() দিয়ে একটি ক্ষুদ্র spinlock বানানো যায়; C++20 থেকে ডিফল্টভাবে তৈরি flag “খালি” অবস্থায় থাকে আর test() দিয়ে শুধু পড়াও যায়।
• C++20-এর wait/notify: a.wait(old) thread-কে ঘুম পাড়িয়ে রাখে, যতক্ষণ মান old থাকে; অন্য thread মান বদলে a.notify_one() বা notify_all() ডাকলে জাগে। ফলে লুপে CPU না পুড়িয়ে একটি পতাকার জন্য অপেক্ষা করা যায় — অনেকটা হালকা condition_variable-এর মতো।
• atomic<shared_ptr<T>> (C++20): পর্ব ১৭-এ দেখেছেন, shared_ptr-এর গোনা atomic হলেও একই shared_ptr ভ্যারিয়েবলকে দুই thread থেকে একসাথে বদলানো নিরাপদ নয়। এই টাইপ সেটি নিরাপদ করে — যেমন একটি কনফিগারেশন, যা এক thread পুরোটা নতুন করে বসায় আর অন্যরা পড়ে। এটি সাধারণত lock-free হয় না, তবু হাতে লেখা কৌশলের চেয়ে অনেক নিরাপদ।

৭ · Memory ordering — আগে ডেটা রাখুন, তারপর পতাকা তুলুন

এবার একটি গভীর কিন্তু জরুরি বিষয়। একটি অ্যাপে loader thread ডিস্ক থেকে একটি রিপোর্ট পড়ে, আর UI thread অপেক্ষা করে একটি “ডেটা তৈরি” পতাকার জন্য। স্বাভাবিক বুদ্ধিতে লেখা হয়: আগে ডেটা লিখি, তারপর পতাকা true করি। UI পতাকা true দেখলে ডেটা পড়বে। এতে ভুল কোথায়?

ভুল হলো, আপনার লেখা ক্রমই যে আসল ক্রম, এমন নিশ্চয়তা নেই। compiler দ্রুত করার জন্য স্বাধীন দুটি লেখার ক্রম বদলে দিতে পারে, আর CPU-ও লেখাগুলো নিজের store buffer-এ জমিয়ে রেখে ভিন্ন ক্রমে মেমরিতে পাঠাতে পারে — একে বলে reordering. এক thread-এর ভেতরে এটা টের পাওয়া যায় না, কারণ ফল একই থাকে। কিন্তু অন্য thread থেকে দেখলে পতাকা আগে, ডেটা পরে পৌঁছাতে পারে। এই নিয়মগুলোর পুরো বিবরণকে বলে C++-এর memory model, আর প্রতিটি atomic কাজে আপনি বলে দিতে পারেন কতটা ক্রম রক্ষা চাই — memory ordering.

ডিফল্ট sequential consistency (memory_order_seq_cst) দিয়ে উপরের পতাকার কোড এমনিতেই সঠিক — ডেটা আর পতাকা আপনার লেখা ক্রমেই দেখা যাবে, যতক্ষণ পতাকাটি std::atomic<bool>. হাতে ক্রম বলতে চাইলে সবচেয়ে প্রচলিত জোড়া হলো acquire/release. দুই thread-এর হস্তান্তরটি ধাপে ধাপে দেখুন:

loader thread               UI thread
─────────────               ─────────
                            while (!ready.load(acquire))
                                ;   // অপেক্ষা
data   = (খালি)
ready  = false

loader thread               UI thread
─────────────               ─────────
data = loadReport(); ✓      (এখনো অপেক্ষা)
     │
     ▼  “এর আগের সব লেখা
        পতাকার সাথে যাবে”

loader thread               UI thread
─────────────               ─────────
data = loadReport();
ready.store(true, release) ──┐
   ▲ উপরের কোনো লেখা         │  “প্যাকেটে” ডেটাসহ
     এর নিচে নামতে পারে না   └──────────►

loader thread               UI thread
─────────────               ─────────
data = loadReport();
ready.store(true, release) ───────► ready.load(acquire) → true
                                    show(data);  → পূর্ণ রিপোর্ট ✓
                            ▲ নিচের কোনো পড়া এর উপরে
                              উঠতে পারে না

loader thread               UI thread
─────────────               ─────────
ready = true;   ← আগে পৌঁছাল!   ready → true
data = loadReport();               show(data); → খালি/আধা ✗
compiler বা CPU ক্রম বদলেছে। সাধারণ bool হলে পতাকাতেই
data race; relaxed হলে পতাকা ঠিক, কিন্তু data-র লেখা-পড়ায়
ক্রম নেই — data-তে data race, তাই এটিও undefined behavior.

তাহলে memory_order_relaxed কোথায় চলে? যেখানে ভ্যারিয়েবলটি নিজেই সব, অন্য কোনো ডেটা পাহারা দেয় না — যেমন hit counter, যা শেষে সব thread join হওয়ার পর পড়া হয় (join নিজেই প্রয়োজনীয় ক্রম দেয়)। কিন্তু relaxed counter দেখে কোনো সিদ্ধান্ত নিয়ে অন্য ডেটা পড়লে, সেটা আর “শুধু গোনা” নয়।

৮ · বড় ছবি — parallel algorithm আর C++26-এর std::execution

অনুচ্ছেদ ৪-এ আমরা নিজে হাতে চার টুকরো করেছি। কিন্তু পর্ব ৩৩-এ দেখেছেন, C++17 থেকে অনেক STL algorithm-কে একটি execution policy দেওয়া যায়, আর লাইব্রেরি নিজেই কাজটা ভাগ করে নেয়:

#include <execution>
#include <numeric>

long long total = std::reduce(std::execution::par,
                              sales.begin(), sales.end(), 0LL);

একটি লাইনে একই কাজ — কয়টি টুকরো, কয়টি thread, সব লাইব্রেরির সিদ্ধান্ত। এখানে std::accumulate নয়, std::reduce, কারণ সমান্তরালে যোগ করতে হলে যোগের ক্রম বদলানোর অনুমতি লাগে। বাস্তব সতর্কতা: GCC-র লাইব্রেরিতে par সত্যিই সমান্তরালে চলতে Intel TBB লাইব্রেরি লাগে (link-এ -ltbb); না থাকলে কাজ ক্রমিকভাবেও চলতে পারে। আর policy-যুক্ত algorithm-এর ভেতর থেকে exception বেরোলে std::terminate হয় — future-এর মতো ফিরে আসে না।

আরেকটু দূরে তাকান। future-এর একটি বড় দুর্বলতা হলো, “এটা শেষ হলে ওটা করো” — এভাবে কাজ জোড়া লাগানো যায় না; get()-এ আটকে থাকতেই হয়। কাজের শৃঙ্খল বানানোর জন্য দীর্ঘ আলোচনার পর std::execution — যাকে senders/receivers বলা হয় (প্রস্তাব P2300) — C++26-এ গৃহীত হয়েছে। এতে একটি কাজ (sender) বর্ণনা করে কী করতে হবে, একটি scheduler ঠিক করে কোথায় চলবে (thread pool, GPU, event loop), আর কাজগুলো পাইপের মতো জোড়া লাগে:

// C++26 — ধারণা দেখানোর জন্য; compiler সমর্থন এখনো আসছে
namespace ex = std::execution;
auto work = ex::schedule(pool.get_scheduler())
          | ex::then([] { return fetchRate(); })
          | ex::then([](double r) { return r * 100; });
auto [result] = std::this_thread::sync_wait(std::move(work)).value();

এখানে কিছুই আগে থেকে চলে না — পুরো শৃঙ্খলটি একটি বর্ণনা, যা sync_wait চালু করে। ভুল আর বাতিল (cancellation) আলাদা পথে বয়ে যায়। পর্ব ৪২-এর coroutine-এর সাথে মিলে এটিই আধুনিক C++-এর async-এর ভবিষ্যৎ। আজ আপনার বাস্তব পছন্দের ক্রম: আগে parallel algorithm, তারপর std::async/future, তারপর thread ও mutex, আর একেবারে শেষে নিজের atomic কৌশল।

৯ · AI-এর যুগে — concurrent কোডের ভুল ধরা

concurrency-তে AI-এর লেখা কোড সবচেয়ে বিপজ্জনক, কারণ ভুল কোডও প্রায়ই টেস্টে পাস করে। আপনার ল্যাপটপে একশোবার চালালে ঠিক আসে; সার্ভারে লাখবারে একবার ভুল আসে। অনলাইনে পুরোনো রীতির (C++11-এর আগের, বা Java থেকে আনা ধারণার) কোড প্রচুর, আর AI সেগুলোই নকল করে। সাধারণ ভুলগুলো:

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

• প্রতিটি std::async-এর future কোনো নামে রাখা, আর policy হিসেবে std::launch::async লেখা
• প্রতিটি get() একবারই ডাকা, আর তার exception কোথায় ধরা হয়, তা দেখেছি
• async-এ reference পাঠালে (std::ref/std::cref), সেই object সব কাজ শেষ হওয়া পর্যন্ত বেঁচে থাকে
• কোডে volatile খুঁজেছি — thread-এর জন্য থাকলে std::atomic দিয়ে বদলেছি
• প্রতিটি memory_order_relaxed-এর জন্য বলতে পারি: এটি কি খাঁটি counter, নাকি অন্য ডেটা পাহারা দেয়?
• -fsanitize=thread দিয়ে build করে কয়েকবার চালিয়েছি — কোনো data race রিপোর্ট নেই