মাল্টিথ্রেডিং — একসাথে অনেক কাজ, কিন্তু নিয়ম মেনে

১ · একসাথে অনেক কাজ — concurrency আর parallelism

একটি চায়ের দোকানের কথা ভাবুন। সকালবেলা ভিড়। দোকানি একাই চা বানাচ্ছেন, ফাঁকে ফাঁকে পরোটা উল্টাচ্ছেন, আবার টাকাও নিচ্ছেন। কোনো এক মুহূর্তে তিনি একটি কাজই করছেন। কিন্তু দ্রুত কাজ বদলান বলে মনে হয় সব একসাথে চলছে। এটাই concurrency — অনেক কাজ একসাথে সামলানো।

এবার দুপুরে দোকানে তিনজন কর্মী এলেন। একজন শুধু চা বানান, একজন পরোটা ভাজেন, একজন টাকা নেন। এখন তিনটি কাজ সত্যিই একই মুহূর্তে হচ্ছে। এটাই parallelism — অনেক কাজ একসাথে করা।

আজকের প্রায় সব ফোন আর ল্যাপটপের CPU multi-core — একটি চিপের ভেতরে ৪, ৮ বা আরও বেশি আলাদা core. কিন্তু সাধারণ একটি C প্রোগ্রাম শুধু একটি core ব্যবহার করে, বাকিগুলো বসে থাকে। সব core কাজে লাগাতে হলে প্রোগ্রামকে কয়েকটি স্বাধীন ধারায় ভাগ করতে হয়। প্রতিটি ধারার নাম thread, আর এই কৌশলের নাম multithreading.

বাস্তবে thread কোথায় লাগে? কয়েকটি পরিচিত উদাহরণ:

• Web server: হাজারো মানুষ একসাথে একটি ওয়েবসাইট খুলছেন। Server অনুরোধগুলো কয়েকটি thread-এ ভাগ করে সামলায়, যাতে কেউ অন্যের জন্য আটকে না থাকেন।
• গেম: একটি thread ছবি আঁকে (render), আরেকটি পদার্থবিদ্যার হিসাব করে — বল কোথায় পড়বে, গাড়ি কোথায় ধাক্কা খাবে।
• মোবাইল অ্যাপ: Android অ্যাপে একটি মূল UI thread বোতাম, স্ক্রল আর অ্যানিমেশন সামলায়। ধীর কাজ (যেমন ইন্টারনেট থেকে ডেটা আনা) সেখানে করলে অ্যাপ জমে যায়, তাই সেগুলো পাঠানো হয় আলাদা thread-এ।

২ · Thread কী — একই ঘরে কয়েকজন কর্মী

আগের পর্বে fork() দিয়ে বানানো নতুন process পেয়েছিল নিজের আলাদা মেমরি — যেন পাশে আরেকটি আলাদা দোকান খোলা হলো। এক দোকানের খাতা অন্য দোকান দেখতে পায় না; কথা বলতে pipe-এর মতো আলাদা পথ লাগে।

Thread হলো একই দোকানে আরেকজন কর্মী নিয়োগ দেওয়া। সবাই একই তাক, একই ক্যাশবাক্স, একই হিসাবের খাতা ব্যবহার করেন। কথা বলা খুব সহজ — খাতায় লিখে দিলেই অন্যজন দেখতে পান। কিন্তু ঠিক এখানেই বিপদ: দুজন একসাথে একই খাতার একই লাইনে লিখতে গেলে গোলমাল অবধারিত।

একটি core-এ কয়েকটি thread থাকলে operating system-এর scheduler তাদের পালা করে চালায়। একটি thread থামিয়ে তার register-গুলো সংরক্ষণ করে আরেকটি thread চালু করার কাজকে বলে context switch. এটি খুব দ্রুত হয়, কিন্তু বিনা খরচে নয় — আর সবচেয়ে গুরুত্বপূর্ণ কথা, কখন থামানো হবে তা আপনি ঠিক করেন না। আপনার কোডের যেকোনো দুটি machine instruction-এর মাঝখানে thread থেমে যেতে পারে। এই একটি সত্য থেকেই এই পর্বের সব সমস্যার জন্ম।

৩ · pthread দিয়ে thread তৈরি — create, join আর তথ্য পাঠানো

Linux, macOS আর অন্য Unix-ধাঁচের সিস্টেমে C-তে thread চালানোর প্রচলিত উপায় হলো pthread (POSIX threads) library. এর জন্য #include <pthread.h> লাগে, আর অনেক সিস্টেমে compile করার সময় -pthread flag দিতে হয়। মূল কাজ দুটি:

Thread-এর ফাংশনের চেহারা সবসময় একই: void *fn(void *arg). void * (পর্ব ১৭) দিয়ে যেকোনো ধরনের তথ্যের ঠিকানা পাঠানো যায়। Join না করলে main শেষ হওয়ার সাথে সাথে পুরো process বন্ধ হয়ে যায় — অন্য thread-গুলো কাজের মাঝপথে থাকলেও।

for (int i = 0; i < 4; i++)
    pthread_create(&t[i], NULL, worker, &i);   /* BUG */

৪ · Race condition — counter++ আসলে তিনটি কাজ

C-তে counter++ দেখতে একটি ছোট্ট কাজ। কিন্তু CPU-র কাছে এটি তিনটি আলাদা ধাপ: (১) মেমরি থেকে counter-এর মান register-এ পড়া, (২) register-এ ১ যোগ করা, (৩) নতুন মান মেমরিতে লেখা। এই ধরনকে বলে read-modify-write. একটি thread-এ কোনো সমস্যা নেই। কিন্তু দুটি thread একই counter বাড়ালে কী হয়? নিচে দুজনেই একবার করে বাড়াচ্ছে — শুরুতে মান ৫, শেষে হওয়ার কথা ৭. “পরে” চাপুন:

1counter = 5;            /* shared */2T1: r1 = counter;       /* read  */3T2: r2 = counter;       /* read  */4T1: r1 = r1 + 1;        /* add   */5T2: r2 = r2 + 1;        /* add   */6T1: counter = r1;       /* write */7T2: counter = r2;       /* write */

সংখ্যা বাড়ানো শুনতে নিরীহ। কিন্তু একই ঘটনা টাকার হিসাবে ঘটলে? ধরুন একটি মোবাইল ব্যাংকিং অ্যাকাউন্টে আছে ১,০০০ টাকা। একই মুহূর্তে দুটি ডিভাইস থেকে টাকা তোলার অনুরোধ এলো — একটি ৭০০, আরেকটি ৫০০. Server দুটি অনুরোধ দুটি thread-এ সামলাচ্ছে, আর প্রত্যেকে “ব্যালান্স দেখো → যথেষ্ট থাকলে কাটো” নিয়ম মানছে:

গ্রাহক মোট ১,২০০ টাকা পেলেন, অথচ অ্যাকাউন্টে ছিল ১,০০০ — আর শেষে ব্যালান্স দেখাচ্ছে ৫০০! সঠিক আচরণ হতো দ্বিতীয় অনুরোধটি বাতিল করা। এই কারণেই আসল লেনদেন-ব্যবস্থায় “পড়া, যাচাই আর লেখা” পুরোটা একটিমাত্র অবিভাজ্য কাজ হিসেবে করা হয়।

এবার আসল কোডে দেখুন। দুটি thread দশ লাখ বার করে একটি সাধারণ long বাড়াচ্ছে, আর পাশে আরও দুটি thread একই কাজ করছে একটি atomic ভ্যারিয়েবলে (atomic কী, তা পরের অংশে বিস্তারিত)। কয়েকবার Run চাপুন:

#include <stdio.h>
#include <pthread.h>
#include <stdatomic.h>
#define N 1000000

long plain = 0;            /* shared, unprotected */
atomic_long safe = 0;      /* shared, atomic */

void *racy(void *p) { (void)p; for (int i = 0; i < N; i++) plain++; return NULL; }
void *atom(void *p) { (void)p; for (int i = 0; i < N; i++) atomic_fetch_add(&safe, 1); return NULL; }

int main(void) {
    pthread_t t[4];
    pthread_create(&t[0], NULL, racy, NULL); pthread_create(&t[1], NULL, racy, NULL);
    pthread_create(&t[2], NULL, atom, NULL); pthread_create(&t[3], NULL, atom, NULL);
    for (int i = 0; i < 4; i++) pthread_join(t[i], NULL);
    printf("expected: %d\n", 2 * N);
    printf("plain++ : got %ld, matched: %s\n", plain, plain == 2L * N ? "yes" : "no");
    printf("atomic  : got %ld, matched: %s\n", (long)safe, safe == 2L * N ? "yes" : "no");
    return 0;
}

৫ · Mutex ও atomic — এক সময়ে একজন

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

অংশ ৪-এর একই দুটি counter++, এবার mutex দিয়ে ঘেরা। খেয়াল করুন T2 কীভাবে অপেক্ষা করছে:

1T1: lock(&m);           /* free: T1 gets it  */2T2: lock(&m);           /* busy: T2 sleeps   */3T1: r1 = counter;4T1: counter = r1 + 1;5T1: unlock(&m);         /* wakes T2          */6T2: r2 = counter;7T2: counter = r2 + 1; unlock(&m);

এবার একটি বাস্তবসম্মত উদাহরণ। ১ থেকে ১০ লাখ পর্যন্ত সব সংখ্যার যোগফল চারটি thread ভাগ করে বের করবে। প্রত্যেকে নিজের ভাগ নিজের local ভ্যারিয়েবলে যোগ করবে, আর শেষে মাত্র একবার lock নিয়ে মোট যোগফলে নিজের অংশ যোগ করবে:

#include <stdio.h>
#include <pthread.h>
typedef struct { long from, to; } Range;
long total = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
void *sum_part(void *arg) {
    Range *r = arg;  long local = 0;          /* own range, own local sum */
    for (long k = r->from; k <= r->to; k++) local += k;   /* no lock needed */
    pthread_mutex_lock(&lock);                /* critical section: one line */
    total += local;
    pthread_mutex_unlock(&lock);  return NULL;
}
int main(void) {
    pthread_t t[4];  Range r[4];              /* one struct per thread, not &i */
    for (int i = 0; i < 4; i++) {
        r[i] = (Range){ i * 250000L + 1, (i + 1) * 250000L };
        pthread_create(&t[i], NULL, sum_part, &r[i]);
    }
    for (int i = 0; i < 4; i++) pthread_join(t[i], NULL);
    printf("total = %ld, formula = %ld\n", total, 1000000L * 1000001L / 2);
    return 0;
}

Atomic — একটি সংখ্যার জন্য হালকা হাতিয়ার

শুধু একটি সংখ্যা বাড়ানো বা কমানোর জন্য পুরো mutex ব্যবহার করা অনেক সময় বাড়াবাড়ি। আধুনিক CPU-তে বিশেষ instruction আছে, যা পড়া-বদলানো-লেখাকে এক ধাক্কায় করে — মাঝখানে অন্য কোনো core ঢুকতে পারে না। একে বলে atomic operation. C11-এ _Atomic বা atomic_long-এর মতো টাইপ আর atomic_fetch_add-এর মতো ফাংশন দিয়ে এটি ব্যবহার করা যায়, যা আপনি অংশ ৪-এর কোডে দেখেছেন।

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

Lock সমস্যা মেটায়, আবার নতুন সমস্যাও আনে। একটি সরকারি অফিসের দৃশ্য ভাবুন। একটি ফাইল অনুমোদন করতে দুটি নথি লাগে — ক আর খ. কর্মকর্তা রহিম নথি ক টেবিলে নিয়ে বসে আছেন, খ-এর জন্য অপেক্ষা করছেন। কর্মকর্তা করিম নথি খ নিয়ে বসে আছেন, ক-এর জন্য অপেক্ষা করছেন। কেউ নিজের নথি ছাড়বেন না। ফাইল চিরকাল আটকে থাকবে। এটাই deadlock.

প্রোগ্রামে এটি ঘটে যখন দুটি thread দুটি mutex উল্টো ক্রমে নেয়। নিচে প্রথমে সমস্যাটি দেখুন, তারপর সমাধান:

1/* version 1: opposite order */2T1: lock(A);3T2: lock(B);4T1: lock(B);   /* waits for T2 */5T2: lock(A);   /* waits for T1 */6/* version 2: always A, then B */7T1: lock(A);8T2: lock(A);   /* waits, holds nothing */9T1: lock(B); work(); unlock(B); unlock(A);10T2: lock(A); lock(B); work(); ...

Deadlock-এর চারটি শর্ত

১৯৭১ সালে Edward Coffman ও তাঁর সহকর্মীরা দেখান, deadlock হতে হলে চারটি শর্ত একসাথে সত্য হতে হয়। এগুলো পরিচিত Coffman conditions নামে:

যেকোনো একটি শর্ত ভাঙলেই deadlock অসম্ভব। Lock ordering ভাঙে চতুর্থ শর্তটি — সবাই একই দিকে এগোলে বৃত্ত তৈরি হতে পারে না। দ্বিতীয় শর্ত ভাঙার উপায় হলো pthread_mutex_trylock: lock না পেলে অপেক্ষা না করে হাতের সবকিছু ছেড়ে দিয়ে পরে আবার চেষ্টা করা।

Deadlock-এর দুই আত্মীয় — livelock আর starvation

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

পর্ব ৩৪-এ আপনি circular buffer বানিয়েছিলেন — নির্দিষ্ট আকারের একটি queue, যার head আর tail ঘুরে আসে। এখন ভাবুন একটি গার্মেন্টস কারখানার সেলাই লাইন: একজন কর্মী শার্ট সেলাই করে টেবিলে রাখেন (producer), আরেকজন টেবিল থেকে নিয়ে ভাঁজ করেন (consumer). টেবিলে জায়গা মাত্র ৩টি শার্টের। একে বলে producer-consumer সমস্যা, আর এটি web server, ভিডিও প্লেয়ার, লগ লেখার সিস্টেম — সবখানে আছে।

নিয়ম দুটি: টেবিল ভরা থাকলে producer অপেক্ষা করবেন, খালি থাকলে consumer. কিন্তু বারবার “খালি হলো?” জিজ্ঞেস করলে (busy waiting) CPU অযথা পুড়ে যায়। সঠিক হাতিয়ার condition variable: একটি thread ঘুমিয়ে পড়ে, আর অন্য thread অবস্থা বদলালে তাকে ডেকে তোলে (signal). pthread_cond_wait ঘুমানোর ঠিক আগে mutex ছেড়ে দেয়, আর জাগার পর আবার mutex নিয়ে তবেই ফেরে।

1/* producer */2lock(&m);3while (count == 3) wait(&not_full, &m);4put(item); count++;5signal(&not_empty); unlock(&m);6/* consumer */7lock(&m);8while (count == 0) wait(&not_empty, &m);9item = take(); count--;10signal(&not_full); unlock(&m);

৮ · বেশি thread মানেই বেশি গতি নয় — thread pool ও Amdahl's law

প্রতিটি কাজের জন্য নতুন thread বানানো আর শেষে ধ্বংস করাও খরচের ব্যাপার। তাই বড় সিস্টেম ব্যবহার করে thread pool: শুরুতেই কয়েকটি thread বানিয়ে রাখা হয়, আর তারা একটি কাজের queue থেকে একটির পর একটি কাজ তুলে নেয়। এটি আসলে অংশ ৭-এর producer-consumer-ই।

Amdahl's law — ধারাবাহিক অংশই গতির সীমা টানে

১৯৬৭ সালে IBM-এর কম্পিউটার স্থপতি Gene Amdahl একটি সরল কিন্তু গভীর হিসাব দেখান। প্রায় প্রতিটি প্রোগ্রামের কিছু অংশ ভাগ করা যায় না — যেমন ফাইল পড়া, শুরুর প্রস্তুতি, শেষে ফল একত্র করা। ধরুন সেই অংশ পুরো সময়ের ভগ্নাংশ s, আর core আছে Nটি। তাহলে সর্বোচ্চ গতি-বৃদ্ধি:

এটিই Amdahl's law. একটি উদাহরণ নিই: প্রোগ্রামের ১০% ধারাবাহিক (s = 0.1), বাকি ৯০% পুরোপুরি ভাগ করা যায়।

লক্ষ করুন: core দ্বিগুণ করলে গতি দ্বিগুণ হয় না, আর অসীম core দিলেও ১০ গুণের বেশি নয় — ঐ ১০% ধারাবাহিক অংশ কেউ ভাগ করে নিতে পারছে না। বাস্তবে অবস্থা আরও খারাপ, কারণ thread বাড়লে lock-এর জন্য কাড়াকাড়ি (contention)-ও বাড়ে।

৯ · AI-এর যুগে multithreading — যে বাগ একবার চালিয়ে ধরা যায় না

Thread-এর বাগ হাজারবারে একবার আসে, আপনার ল্যাপটপে না এসে ৬৪ core-এর server-এ আসে, আর printf যোগ করলে সময়ের হিসাব বদলে লুকিয়ে পড়ে। তাই AI-এর লেখা thread কোড প্রথমবার ঠিক চললেও সেটি কোনো প্রমাণ নয়।

যাচাইয়ের টুল

সবচেয়ে শক্তিশালী হাতিয়ার ThreadSanitizer (TSan) — GCC আর Clang দুটিতেই আছে। এটি প্রোগ্রাম চলার সময় প্রতিটি মেমরি-পড়া ও লেখা নজরে রাখে, আর দুটি thread সুরক্ষা ছাড়া একই জায়গায় হাত দিলে কোন দুটি লাইনে ঘটেছে তা জানিয়ে দেয় — এমনকি সেই চালানোয় ফল ঠিক এলেও। পর্ব ৩১-এর AddressSanitizer-এর মতোই এটি একটি sanitizer. Valgrind-এর Helgrind টুলও একই ধরনের ভুল আর lock-এর ক্রমভঙ্গ খোঁজে।

gcc -g -fsanitize=thread race.c -o race -pthread
./race
# WARNING: ThreadSanitizer: data race ... (line numbers of both accesses)

এর সাথে লাগে stress test: প্রোগ্রামটি একটি লুপে শত শত বার চালানো, thread-এর সংখ্যা বাড়িয়ে-কমিয়ে, যাতে বিরল interleaving-ও কোনো এক সময় ঘটে।

AI সাধারণত যেসব thread-ভুল করে

AI-এর লেখা thread কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি ভাগ করা ভ্যারিয়েবলের জন্য বলতে পারি — কোন mutex বা atomic তাকে রক্ষা করছে
• প্রতিটি lock-এর বিপরীতে প্রতিটি পথে (error-এর পথসহ) একটি unlock আছে
• একাধিক lock সবখানে একই ক্রমে নেওয়া হয়েছে
• প্রতিটি pthread_cond_wait একটি while লুপের ভেতরে
• কোনো thread লুপ-ভ্যারিয়েবল বা শেষ হয়ে যাওয়া local ভ্যারিয়েবলের ঠিকানা পায়নি; সব thread join করা হয়েছে
• -fsanitize=thread দিয়ে চালিয়ে একটিও সতর্কবার্তা নেই, আর অন্তত কয়েকশো বার চালিয়ে ফল প্রতিবার একই এসেছে