থ্রেড — কেন, কীভাবে আর threading model

১ · থ্রেড কী — এক প্রসেসে একাধিক কাজের ধারা

পর্ব ৮-এ দেখেছেন, একটি process হলো চলমান প্রোগ্রাম — নিজের মেমরি, নিজের খোলা ফাইল আর CPU-র নিজের অবস্থা নিয়ে। এতদিন আমরা ধরে নিয়েছি, প্রতিটি প্রসেসে একটিমাত্র “কাজের ধারা” আছে: CPU একটি নির্দেশ চালায়, তারপর পরেরটি, এক লাইনে। কিন্তু আপনার ফোনের ব্রাউজার একই সাথে পাতা নামাচ্ছে, ছবি ডিকোড করছে, আপনার আঙুলের স্ক্রল সামলাচ্ছে। এগুলো কি একটির পর একটি চলে?

সংজ্ঞাটি এবার নির্দিষ্ট করি। থ্রেড হলো CPU ব্যবহারের মৌলিক একক: একটি thread ID, একটি program counter, এক সেট register আর একটি stack. একই প্রসেসের থ্রেডগুলো বাকি সবকিছু ভাগ করে নেয়। প্রচলিত প্রসেস মানে “একটি থ্রেডওয়ালা প্রসেস”; একাধিক থ্রেড থাকলে তাকে বলে multithreaded প্রসেস।

লক্ষ করুন, stack “নিজের” মানে আলাদা জায়গায় রাখা — কিন্তু একই address space-এর ভেতরে। তাই একটি থ্রেড চাইলে পয়েন্টার দিয়ে আরেকজনের stack-এ লিখতেও পারে; কোনো হার্ডওয়্যার তাকে থামাবে না। প্রসেসের মধ্যে যে দেয়াল (আলাদা page table) থাকে, থ্রেডের মধ্যে তা নেই। এটিই থ্রেডের শক্তি, আবার এটিই তার বিপদ।

নিচের ডায়াগ্রামে একটি প্রসেসের মেমরি ধাপে ধাপে দেখুন — একটি থ্রেড থেকে তিনটি, তারপর একই কাজ দুটি আলাদা প্রসেস দিয়ে করলে কী হয়।

+------------------------------------------+
| code   : main(), worker()                |
| data   : int g = 0                       |
| heap   : malloc'd buffers                |
| files  : fd 0, 1, 2, 3                   |
+------------------------------------------+
| thread T1 : PC, registers, stack         |
+------------------------------------------+
  kernel keeps: 1 PCB (+ state of T1)

+------------------------------------------+
| code   : main(), worker()      SHARED    |
| data   : int g = 0             SHARED    |
| heap   : malloc'd buffers      SHARED    |
| files  : fd 0, 1, 2, 3         SHARED    |
+-------------+-------------+--------------+
| thread T1   | thread T2   | thread T3    |
| PC, regs    | PC, regs    | PC, regs     |
| own stack   | own stack   | own stack    |
| own errno   | own errno   | own errno    |
+-------------+-------------+--------------+

+------------------------------------------+
| data   : int g = 42   <-- written by T1  |
+-------------+-------------+--------------+
| T1: g = 42  | T2 reads g  | T3 reads g   |
|             |   -> 42     |   -> 42      |
+-------------+-------------+--------------+
  one copy of g, one address (&g) for all

+------------------+     +------------------+
| parent process   |     | child process    |
| code             |     | code (shared RO) |
| data: g = 0      |     | data: g = 99     |
| heap (own copy)  |     | heap (own copy)  |
| files (own table)|     | files (own table)|
| T1: PC, stack    |     | T1': PC, stack   |
+------------------+     +------------------+
  child sets g = 99 -> parent still sees 0

PCB (per process)        TCB (per thread)
-----------------        ----------------------
pid, parent, uid         tid, state, priority
page table / mm          saved PC, SP, registers
open-file table          kernel stack pointer
signal handlers          signal mask, TLS base
list of its TCBs  --->   [T1] [T2] [T3]
Linux: one task_struct per thread,
       all sharing one mm_struct

TCB বনাম PCB

Context switch-এর সময় (পর্ব ৯) kernel-কে চলতি কাজের register কোথাও রেখে দিতে হয়। থ্রেড আসার পর সেই “কোথাও” হলো Thread Control Block (TCB). প্রসেসের সম্পদের হিসাব থাকে PCB-তে, আর CPU-তে চলার জন্য যা লাগে তা থাকে TCB-তে। একই প্রসেসের দুই থ্রেডের মধ্যে সুইচে শুধু TCB বদলায়; page table বদলাতে হয় না, তাই TLB-র ঠিকানা-অনুবাদও (পর্ব ৩৩) অটুট থাকে — এজন্যই এই সুইচ সাধারণত সস্তা।

নিজের চোখে দেখা — থ্রেড ভাগ করে, প্রসেস কপি করে

নিচের প্রোগ্রাম প্রথমে fork করে child-কে দিয়ে global g বদলায়, তারপর দুটি থ্রেড চালিয়ে একটিকে দিয়ে g বদলায়। প্রতিটি থ্রেড &g আর নিজের একটি লোকাল ভ্যারিয়েবলের ঠিকানা লিখে রাখে। ঠিকানা প্রতি রানে বদলায়, তাই প্রোগ্রাম ঠিকানা ছাপে না — শুধু সম্পর্ক ছাপে (“একই কি না”). থ্রেড তৈরির API (pthread_create, pthread_join) এখানে শুধু হালকাভাবে; বিস্তারিত পর্ব ১৫-এ।

#include <pthread.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

int g = 0;                          /* global: one copy per process */
uintptr_t gaddr[2], laddr[2];       /* addresses seen by each thread */

static void *worker(void *arg) {
    long id = (long)arg;
    int local = 0;                  /* lives on THIS thread's own stack */
    gaddr[id] = (uintptr_t)&g;
    laddr[id] = (uintptr_t)&local;
    if (id == 0) g = 42;            /* thread 0 writes the shared global */
    return NULL;
}

int main(void) {
    fflush(stdout);                 /* nothing buffered before fork */
    pid_t pid = fork();
    if (pid == 0) { g = 99; _exit(0); }          /* child changes ITS copy */
    waitpid(pid, NULL, 0);
    printf("child process set g = 99 -> parent sees g = %d\n", g);

    pthread_t t[2];
    for (long i = 0; i < 2; i++) pthread_create(&t[i], NULL, worker, (void *)i);
    for (int i = 0; i < 2; i++) pthread_join(t[i], NULL);
    printf("thread 0 set g = 42      -> main sees g = %d\n", g);
    printf("&g same in both threads and main: %s\n",
           gaddr[0] == gaddr[1] && gaddr[0] == (uintptr_t)&g ? "yes" : "no");
    printf("&local different in each thread: %s\n", laddr[0] != laddr[1] ? "yes" : "no");
    uintptr_t d = laddr[0] > laddr[1] ? laddr[0] - laddr[1] : laddr[1] - laddr[0];
    printf("gap between the two locals: about %lu KiB\n", (unsigned long)(d / 1024));
    return 0;
}

child process set g = 99 -> parent sees g = 0
thread 0 set g = 42      -> main sees g = 42
&g same in both threads and main: yes
&local different in each thread: yes
gap between the two locals: about 8196 KiB

২ · থ্রেড কেন — চারটি সুবিধা

প্রসেস তো আগে থেকেই ছিল; একাধিক কাজ একসাথে করতে অনেকগুলো প্রসেস চালালেই হতো। তবু প্রায় সব আধুনিক অ্যাপ থ্রেড ব্যবহার করে। পাঠ্যবইয়ে চারটি সুবিধার কথা বলা হয়:

খরচ কত কম — সংখ্যা নিয়ে সাবধানে

পাঠ্যবইয়ে (যেমন Silberschatz-দের Operating System Concepts) পুরোনো Solaris-এর একটি মাপ উদ্ধৃত হয়: প্রসেস তৈরি থ্রেডের চেয়ে প্রায় ৩০ গুণ ধীর, আর প্রসেস-সুইচ থ্রেড-সুইচের চেয়ে প্রায় ৫ গুণ। আজকের Linux-এ fork নিজেই copy-on-write দিয়ে অনেক দ্রুত, তাই অনুপাত মেশিন, kernel আর প্রসেসের মেমরির আকারভেদে অনেক বদলায়। সাধারণ একটি Linux মেশিনে একটি থ্রেড তৈরি আর join করতে সাধারণত কয়েক থেকে কয়েক দশ মাইক্রোসেকেন্ড লাগে; fork আর wait-এ প্রায়ই তার কয়েক গুণ, আর বড় মেমরির প্রসেসে আরও বেশি (page table কপি করতে হয়). সংখ্যা মুখস্থ না করে নিজের মেশিনে মেপে দেখাই ঠিক।

থ্রেডের মেমরি-খরচ মূলত তার stack. Linux-এ glibc সাধারণত নতুন থ্রেডকে ulimit -s-এর সমান (প্রায়ই ৮ MiB) virtual stack দেয়, Windows-এ ডিফল্ট সাধারণত ১ MB. এগুলো virtual জায়গা — যতটুকু সত্যিই ছোঁয়া হয়, ততটুকুই আসল RAM নেয়। তবু হাজার হাজার থ্রেডে address space, kernel stack আর scheduler-এর কাজ বাড়ে। অংশ ৫-এ দেখবেন, এ কারণেই Go আর Java লাখো “হালকা থ্রেড” আনতে অন্য পথ নিয়েছে।

৩ · Concurrency, parallelism আর Amdahl's law

পর্ব ২-এর কথা মনে করুন: concurrency মানে একাধিক কাজ একই সময়কাল জুড়ে এগোনো — এক core-এ পালা করে হলেও; parallelism মানে একই মুহূর্তে সত্যিই একসাথে চলা, যার জন্য একাধিক core লাগে। এক core-এ চার থ্রেড concurrent, কিন্তু parallel নয়। চার core-এ চার থ্রেড দুটোই।

কাজ ভাগ করার দুই ধরন আছে। Data parallelism: একই কাজ ডেটার আলাদা অংশে — যেমন ১ কোটি সংখ্যার যোগফল চার থ্রেডে চার ভাগে। Task parallelism: আলাদা আলাদা কাজ আলাদা থ্রেডে — যেমন একটি থ্রেড ফাইল পড়ে, একটি compress করে, একটি নেটওয়ার্কে পাঠায়। বাস্তবের প্রোগ্রামে দুটোই মেশানো থাকে।

Amdahl's law — প্রমাণসহ

১৯৬৭ সালে IBM-এর কম্পিউটার স্থপতি Gene Amdahl একটি সম্মেলনে দেখান, বহু processor দিয়ে গতি বাড়ানোর একটি কঠিন সীমা আছে। ধরা যাক একটি প্রোগ্রাম এক core-এ চলতে T(১) সময় নেয়। এর একটি অংশ শুধু ধারাবাহিকভাবেই চলতে পারে (serial — যেমন ইনপুট পড়া, ফল একত্র করা), বাকিটা পুরোপুরি ভাগ করা যায়। সমান্তরাল অংশের ভগ্নাংশ p (০ ≤ p ≤ ১).

1. এক core-এ: T(১) = (১−p)·T(১) + p·T(১). সুবিধার জন্য T(১) = ১ ধরি।
2. n core-এ serial অংশ এক core-এই চলে, তাই তার সময় একই থাকে: (১−p).
3. সমান্তরাল অংশ সবচেয়ে ভালো ক্ষেত্রে n ভাগে সমান ভাগ হয়: সময় p/n. সমন্বয়, যোগাযোগ বা অসম ভাগের খরচ থাকলে সময় আরও বেশি — কখনো কম নয় (cache-এর বিশেষ প্রভাব বাদে; ভাবনার প্রশ্ন ৩ দেখুন).
4. তাই T(n) ≥ (১−p) + p/n, আর speedup S(n) = T(১)/T(n):

n যত বড় হয়, p/n তত শূন্যের কাছে যায়, হর যায় (১−p)-এর দিকে। তাই কোনো সংখ্যক core-এই speedup এর বেশি হয় না:

সঙ্গে আরেকটি মাপ কাজে লাগে — efficiency E = S/n, অর্থাৎ প্রতিটি core গড়ে কতটা কাজে লাগল। নিচের ডায়াগ্রামে একটি পরীক্ষার ধাঁচের অঙ্ক ধাপে ধাপে করা হলো।

1T(1) = 100 s; serial 20 s, parallel 80 s2p = 80 / 100 = 0.83n = 4: parallel part = 80 / 4 = 20 s4T(4) = 20 + 20 = 40 s; S = 100 / 405check: 1 / (0.2 + 0.8/4) = 1 / 0.46n = 16: T = 20 + 80/16 = 25 s7n -> inf: T -> 20 s; S -> 1/(1-p)8want S = 4: 0.2 + 0.8/n = 1/490.8/n = 0.05  ->  n = 16

আরও কয়েকটি পরীক্ষার ধাঁচের অঙ্ক

• সরাসরি: p = ০.৬, n = ৪ → S = ১/(০.৪ + ০.১৫) = ১/০.৫৫ ≈ ১.৮২.
• সর্বোচ্চ speedup: ২৫% কাজ serial হলে সর্বোচ্চ S = ১/০.২৫ = ৪ — ১,০০০ core দিলেও।
• কত core: p = ০.৯৫, লক্ষ্য S = ১০ → ০.০৫ + ০.৯৫/n = ০.১ → ০.৯৫/n = ০.০৫ → n = ১৯.
• সম্ভব কি না: p = ০.৯ দিয়ে S = ১২? সীমা ১/০.১ = ১০, তাই অসম্ভব।
• একই সূত্র, অন্য প্রসঙ্গ: একটি ফাংশন মোট সময়ের ৪০% নেয়; সেটিকে ৪ গুণ দ্রুত করলে পুরো প্রোগ্রামের S = ১/(০.৬ + ০.৪/৪) = ১/০.৭ ≈ ১.৪৩. Computer architecture-এর বইয়ে Amdahl's law এই রূপেই আসে — “যে অংশ উন্নত করছেন, সেটি মোট কাজের কত ভাগ?”

নিচের ছোট simulator তিনটি p-এর জন্য ১ থেকে ৬৪ core-এ speedup-এর টেবিল বানায়, সাথে প্রতিটির সীমা, ৬৪ core-এ efficiency, আর সীমার ৯০%-এ পৌঁছাতে কত core লাগে:

// Amdahl's law: S(n) = 1 / ((1 - p) + p / n)
const ps = [0.5, 0.9, 0.95];
const ns = [1, 2, 4, 8, 16, 32, 64];
const S = (p, n) => 1 / ((1 - p) + p / n);
const col = (x) => x.padStart(8);

console.log('cores |' + ps.map(p => col('p=' + p)).join(' |'));
console.log('------+' + ps.map(() => '-'.repeat(9)).join('+'));
for (const n of ns) {
  console.log(String(n).padStart(5) + ' |' + ps.map(p => col(S(p, n).toFixed(2))).join(' |'));
}
console.log('limit |' + ps.map(p => col((1 / (1 - p)).toFixed(2))).join(' |'));
console.log('');
for (const p of ps) {
  const eff = S(p, 64) / 64 * 100;
  const goal = 0.9 / (1 - p);               // 90% of the limit
  let n = 1;
  while (S(p, n) < goal - 1e-9) n++;
  console.log(`p=${p}: efficiency at 64 cores = ${eff.toFixed(1)}%, cores for 90% of limit = ${n}`);
}
console.log(`Gustafson, p=0.95, n=64: S = 0.05 + 0.95*64 = ${(0.05 + 0.95 * 64).toFixed(2)}`);

cores |   p=0.5 |   p=0.9 |  p=0.95
------+---------+---------+---------
    1 |    1.00 |    1.00 |    1.00
    2 |    1.33 |    1.82 |    1.90
    4 |    1.60 |    3.08 |    3.48
    8 |    1.78 |    4.71 |    5.93
   16 |    1.88 |    6.40 |    9.14
   32 |    1.94 |    7.80 |   12.55
   64 |    1.97 |    8.77 |   15.42
limit |    2.00 |   10.00 |   20.00

p=0.5: efficiency at 64 cores = 3.1%, cores for 90% of limit = 9
p=0.9: efficiency at 64 cores = 13.7%, cores for 90% of limit = 81
p=0.95: efficiency at 64 cores = 24.1%, cores for 90% of limit = 171
Gustafson, p=0.95, n=64: S = 0.05 + 0.95*64 = 60.85

Gustafson's law — অন্য দিক থেকে দেখা

Amdahl ধরে নিয়েছিলেন সমস্যার আকার স্থির — একই কাজ, বেশি core. ১৯৮৮ সালে Sandia National Laboratories-এর John Gustafson লক্ষ করেন, বাস্তবে বেশি core পেলে মানুষ সাধারণত বড় সমস্যা সমাধান করেন — একই সময়ে আরও সূক্ষ্ম আবহাওয়ার মডেল, আরও বড় ছবি। n core-এর রানে serial অংশের ভগ্নাংশ (১−p) ধরে তিনি “scaled speedup” দেন:

p = ০.৯৫, n = ৬৪ হলে S_G = ০.০৫ + ৬০.৮ = ৬০.৮৫, যেখানে একই p-তে Amdahl দেয় প্রায় ১৫.৪২. দুটি সূত্র পরস্পরবিরোধী নয় — তারা আলাদা প্রশ্নের উত্তর দেয়। Amdahl: “এই নির্দিষ্ট কাজ কত দ্রুত হবে?” Gustafson: “একই সময়ে কত বড় কাজ করা যাবে?” আর এখানে p মাপা হয় আলাদাভাবে — Gustafson-এ সমান্তরাল রানে, Amdahl-এ এক core-এর রানে।

৪ · User-level thread বনাম kernel-level thread

থ্রেড কে চালায় — kernel, না প্রোগ্রামের ভেতরের একটি library? এই প্রশ্নের দুই উত্তর থেকে দুই ধরনের থ্রেড।

দুই দিকের সেরাটা নেওয়ার চেষ্টাই পরের অংশের threading model. মনে রাখার মতো একটি কথা: আধুনিক user-level runtime (Go, Java virtual thread) blocking সমস্যা এড়াতে চালাকি করে — থ্রেড ধীর কাজে গেলে runtime নিজেই অন্য kernel thread-এ বাকিদের সরিয়ে দেয়, বা blocking কাজটিকে non-blocking I/O-তে বদলে নেয়।

৫ · Threading model — many-to-one, one-to-one, many-to-many

User thread শেষ পর্যন্ত CPU-তে চলে কোনো না কোনো kernel thread-এর ওপর চড়ে। কয়টি user thread কয়টি kernel thread-এ বসবে, সেই সম্পর্ককে বলে threading model. তিনটি মূল নকশা:

Many-to-many-র একটি রূপ two-level model: M:N-এর পাশাপাশি কোনো কোনো থ্রেডকে একটি kernel thread-এ স্থায়ীভাবে বেঁধে (bound) রাখা যায়। পুরোনো Solaris-এ ঠিক এটি ছিল; সেখানে user thread আর kernel thread-এর মাঝের ধাপটির নাম ছিল lightweight process (LWP). LWP নামটি আজও টিকে আছে — Linux-এর ps -L-এ থ্রেড ID-র কলামের নাম LWP.

Many-to-one-এর মূল দুর্বলতা আর one-to-one কীভাবে তা এড়ায়, নিচে সময় ধরে দেখুন। ধরা যাক প্রসেসে তিনটি থ্রেড, মেশিনে দুটি core, আর T1 ডিস্ক থেকে পড়তে read() ডাকে, যাতে ১০ মিলিসেকেন্ড লাগে।

1t=0   T1, T2, T3 ready; 2 cores2t=1   T1: read(fd, buf, 4096)3t=1   kernel: disk busy, block caller4t=1..11  waiting for the disk5t=11  disk interrupt: data ready6t=12  everyone can run again

M:N আবার ফিরে এসেছে — runtime-এর ভেতরে

১৯৯০-এর দশক আর ২০০০-এর গোড়ায় অনেক Unix M:N নিয়ে পরীক্ষা করেছিল, কিন্তু kernel-স্তরে বেশিরভাগই পরে 1:1-এ ফিরে যায় (ভাবনার প্রশ্ন ১ দেখুন). অথচ আজ M:N খুব জনপ্রিয় — তবে OS-এর থ্রেড library-তে নয়, ভাষার runtime-এ:

• Go-র goroutine: Go runtime-এর scheduler অনেক goroutine-কে অল্প কয়েকটি OS thread-এ চালায়; একসাথে কয়টি OS thread Go কোড চালাবে, তা ঠিক করে GOMAXPROCS (ডিফল্ট সাধারণত CPU-র সংখ্যা). Goroutine-এর stack ছোট (কয়েক KB) দিয়ে শুরু হয়ে দরকারমতো বাড়ে, তাই লাখো goroutine সাধারণ ব্যাপার। কোনো goroutine blocking system call-এ গেলে runtime বাকিদের অন্য OS thread-এ সরিয়ে দেয়।
• Java-র virtual thread: Java 21 (২০২৩) থেকে স্থায়ী বৈশিষ্ট্য। অনেক virtual thread অল্প কয়েকটি সাধারণ (platform) thread-এর ওপর চলে, যাদের বলে carrier thread. Virtual thread blocking I/O-তে গেলে JVM তাকে carrier থেকে নামিয়ে রাখে, carrier অন্য কাজ নেয়। শুরুর সংস্করণগুলোতে synchronized ব্লকের ভেতরে আটকালে virtual thread carrier-কে আটকে রাখত (“pinning”); পরের সংস্করণে এর অনেকটা সমাধান হয়েছে — ব্যবহারের আগে নিজের JDK-র নথি দেখে নিন।
• Erlang/Elixir-এর হালকা “process”-ও একই ধারণা: BEAM virtual machine প্রতি core-এ একটি scheduler চালিয়ে লাখো process ভাগ করে চালায়।

এরা কেন সফল, যেখানে পুরোনো OS-স্তরের M:N কষ্টে পড়েছিল? কারণ ভাষার runtime জানে কোন কাজ blocking, stack নিজের মতো ছোট-বড় করতে পারে, আর নিজের I/O ব্যবস্থা (Linux-এ epoll, পর্ব ৩৯) দিয়ে blocking কাজ এড়াতে পারে — C library-র পক্ষে যা সাধারণভাবে করা কঠিন।

৬ · Linux-এ থ্রেড আসলে task — clone() আর /proc

Linux-এর নকশায় একটি সুন্দর সরলতা আছে: kernel “প্রসেস” আর “থ্রেড” আলাদা করে চেনে না, চেনে শুধু task — প্রতিটির একটি task_struct. নতুন task তৈরি হয় clone() system call দিয়ে, আর কোন কোন জিনিস parent-এর সাথে ভাগ হবে তা ঠিক করে দেয় একগুচ্ছ flag. সব ভাগ করলে সেটি থ্রেড, কিছুই ভাগ না করলে fork-এর মতো নতুন প্রসেস। মাঝামাঝি সংমিশ্রণও সম্ভব — container-এর namespace (পর্ব ৫১) এই একই ব্যবস্থার আরেকটি ব্যবহার।

/* roughly what glibc's pthread_create asks the kernel for */
int flags = CLONE_VM        /* share the address space (memory)      */
          | CLONE_FS        /* share cwd, root, umask                */
          | CLONE_FILES     /* share the open-file table             */
          | CLONE_SIGHAND   /* share signal handlers                 */
          | CLONE_THREAD    /* same thread group: same PID to users  */
          | CLONE_SYSVSEM   /* share System V semaphore undo values  */
          | CLONE_SETTLS    /* give the new task its own TLS area    */
          | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID;
/* new stack (from mmap) + flags -> clone() / clone3() */

/* fork(), by contrast: no sharing flags, only SIGCHLD on exit */

এই flag-গুলোর মধ্যে মূল হলো CLONE_VM — একই মেমরি — আর CLONE_THREAD — একই “thread group”. Thread group থাকায় সব থ্রেড user-এর চোখে একই PID দেখায় (getpid() সবার জন্য একই), আর প্রতিটির আলাদা thread ID (gettid()). প্রধান থ্রেডের TID আর প্রসেসের PID সমান। নতুন glibc-তে kernel সমর্থন করলে clone3() ব্যবহার হয়, ধারণা একই।

যেহেতু প্রতিটি থ্রেড একটি task, /proc/<pid>/task/ ডিরেক্টরিতে প্রতিটি থ্রেডের একটি করে উপ-ডিরেক্টরি থাকে (নাম = TID), আর /proc/<pid>/status-এর Threads: লাইন সংখ্যা জানায়। নিচের প্রোগ্রাম তিনটি থ্রেড তৈরি করে একটি pipe-এর read()-এ আটকে রাখে, তখন /proc/self/task-এ নিজের task গোনে, তারপর pipe বন্ধ করে সবাইকে ছেড়ে দেয়:

#define _DEFAULT_SOURCE
#include <dirent.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

static int pfd[2];                         /* workers wait on this pipe */

static int tasks(void) {                   /* entries in /proc/self/task */
    int n = 0;
    DIR *d = opendir("/proc/self/task");
    for (struct dirent *e; d && (e = readdir(d)) != NULL; )
        if (e->d_name[0] != '.') n++;
    if (d) closedir(d);
    return n;
}
static void *worker(void *arg) {
    char c;
    while (read(pfd[0], &c, 1) > 0) { }     /* blocks until EOF */
    return arg;
}
int main(void) {
    pthread_t t[3];
    if (pipe(pfd) != 0) return 1;
    printf("before:                     %d task(s)\n", tasks());
    for (int i = 0; i < 3; i++) pthread_create(&t[i], NULL, worker, NULL);
    printf("3 workers blocked in read:  %d task(s)\n", tasks());
    close(pfd[1]);                         /* EOF wakes every worker */
    for (int i = 0; i < 3; i++) pthread_join(t[i], NULL);
    for (int i = 0; i < 200 && tasks() > 1; i++) usleep(1000);  /* see below */
    printf("after join:                 %d task(s)\n", tasks());
    return 0;
}

before:                     1 task(s)
3 workers blocked in read:  4 task(s)
after join:                 1 task(s)

Shell থেকেও থ্রেড দেখা যায়। ps -L প্রতিটি থ্রেডের জন্য একটি সারি দেখায় (LWP = thread ID, NLWP = থ্রেডের সংখ্যা); top -H থ্রেড ধরে CPU দেখায়। এই পাতার bash রানারে একটি সাধারণ shell-এর অবস্থা দেখুন:

echo "== this bash shell =="
echo "entries in /proc/\$\$/task: $(ls /proc/$$/task | wc -l)"
grep '^Threads' /proc/$$/status
[ -d /proc/$$/task/$$ ] && echo "main thread's TID equals the PID: yes"
echo
echo "== ps -L: one row per thread (LWP = thread id, NLWP = count) =="
ps -L -o nlwp,comm -p $$
echo
echo "== CPUs this container may use =="
nproc
echo
echo "== thread count (NLWP) of every process here =="
ps -eo nlwp,comm --no-headers | sort -rn | head -n 5

== this bash shell ==
entries in /proc/$$/task: 1
Threads:	1
main thread's TID equals the PID: yes

== ps -L: one row per thread (LWP = thread id, NLWP = count) ==
NLWP COMMAND
   1 bash

== CPUs this container may use ==
2

== thread count (NLWP) of every process here ==
   1 sort
   1 ps
   1 podman-init
   1 head
   1 bash

# Linux, any process (here PID 1234):
ps -o nlwp= -p 1234            # e.g.  37
ls /proc/1234/task | wc -l     # same number
top -H -p 1234                 # live, one line per thread

# macOS:
ps -M 1234                     # one line per thread

# Windows PowerShell:
(Get-Process -Id 1234).Threads.Count
# Task Manager -> Details -> right-click header -> add "Threads"

৭ · থ্রেডের ঝামেলা — fork, signal, cancellation আর TLS

প্রসেসের জন্য বানানো পুরোনো Unix ধারণাগুলো থ্রেড আসার পর নতুন প্রশ্ন তোলে। পরীক্ষায় আর বাস্তব debugging-এ এগুলো বারবার আসে।

১. Multithreaded প্রোগ্রামে fork()

আট থ্রেডের একটি প্রসেস fork করলে child-এ কয়টি থ্রেড থাকবে? দুটি সম্ভাব্য নকশা ছিল — সব থ্রেড কপি, বা শুধু যে থ্রেড fork ডেকেছে সেটি। POSIX দ্বিতীয়টি বেছে নিয়েছে: child-এ শুধু fork-ডাকা থ্রেডের একটি কপি থাকে, যদিও পুরো মেমরি (অন্য থ্রেডদের stack আর heap-সহ) কপি হয়। (পুরোনো Solaris-এ সব থ্রেড কপি করার আলাদা একটি call-ও ছিল।) সাধারণত fork-এর পরপরই exec (পর্ব ১০) হয়, তখন সব থ্রেড কপি করা অর্থহীন হতো। কিন্তু exec না করলে একটি লুকোনো ফাঁদ আছে:

1parent T1: lock(&log_lock); writing log ...2parent T2: pid = fork();3kernel: copy memory; child gets ONLY T24parent T1: unlock(&log_lock);5child T2': lock(&log_lock);  -> waits6fix: exec() at once, or posix_spawn()

২. Signal কোন থ্রেডে যায়

Signal (পর্ব ১৩) ছিল প্রসেসের জন্য বানানো। থ্রেড আসার পর POSIX নিয়ম দাঁড়াল: signal-এর handler আর ব্যবস্থা প্রসেস-ব্যাপী (সব থ্রেডের এক), কিন্তু signal mask প্রতিটি থ্রেডের নিজের (pthread_sigmask). ভুল কাজের ফলে আসা signal, যেমন SIGSEGV বা SIGFPE, যায় সেই থ্রেডেই যে ভুলটি করেছে। pthread_kill() দিয়ে নির্দিষ্ট থ্রেডে পাঠানো যায়। আর পুরো প্রসেসকে পাঠানো signal (যেমন kill কমান্ডের SIGTERM) kernel দেয় এমন যেকোনো একটি থ্রেডকে, যে সেটি block করেনি। প্রচলিত নিরাপদ কৌশল: সব থ্রেডে signal block করে একটিমাত্র নির্দিষ্ট থ্রেড sigwait()-এ বসিয়ে রাখা। Windows-এ Unix-ধাঁচের signal নেই; কাছাকাছি ধারণা asynchronous procedure call (APC), যা নির্দিষ্ট থ্রেডকে লক্ষ্য করে পাঠানো হয়।

৩. Thread cancellation — অন্য থ্রেডকে থামানো

ধরুন পাঁচটি থ্রেড একটি বড় ডেটাবেসে খুঁজছে; একটি উত্তর পেয়ে গেলে বাকিদের থামানো দরকার। POSIX-এ এর নাম thread cancellation (pthread_cancel()), আর এর দুই ধরন:

অন্য ভাষাতেও একই শিক্ষা: Java-র Thread.stop() বহু বছর আগে অপ্রচলিত (deprecated) ঘোষণা হয়, কারণ সেটি থ্রেডকে যেকোনো জায়গায় থামাত; সাম্প্রতিক Java-তে এটি আর কাজই করে না। এখন পথ হলো interrupt() — একটি অনুরোধ, যা থ্রেড নিজে যাচাই করে সাড়া দেয়। Go-তে এই কাজটি করে context — সহযোগিতামূলক বাতিলকরণ।

৪. Thread-local storage (TLS)

কিছু ডেটা প্রতিটি থ্রেডের আলাদা কপি দরকার, অথচ ফাংশন থেকে ফাংশনে আর্গুমেন্ট হিসেবে পাঠানো ঝামেলা — যেমন errno: দুই থ্রেড একসাথে system call করলে একজনের ত্রুটি আরেকজনের errno নষ্ট করবে, যদি errno একটিই global হয়। সমাধান thread-local storage: ভ্যারিয়েবলটি দেখতে global, কিন্তু প্রতিটি থ্রেড নিজের কপি পায়। C11-এ _Thread_local (C23-এ thread_local), GCC-তে __thread, C++-এ thread_local, Windows-এ TlsAlloc() বা __declspec(thread), Java-তে ThreadLocal. Stack-এর লোকাল ভ্যারিয়েবল থেকে পার্থক্য হলো, TLS ফাংশন শেষ হলেও টিকে থাকে — থ্রেড যতক্ষণ আছে।

৫. Thread pool — শুধু পরিচয়

একটি ওয়েব সার্ভার প্রতিটি অনুরোধে নতুন থ্রেড বানালে দুটি সমস্যা: প্রতিবার তৈরি আর ধ্বংসের খরচ, আর হঠাৎ ভিড়ে হাজার হাজার থ্রেড তৈরি হয়ে মেমরি আর scheduler-এর ভার। Thread pool শুরুতেই নির্দিষ্ট সংখ্যক থ্রেড তৈরি করে রাখে; কাজ আসে একটি queue-তে, খালি থ্রেড একটি কাজ তুলে নেয়, শেষ করে আবার queue দেখে। পোশাক কারখানার সেলাই লাইনের মতো — প্রতিটি অর্ডারের জন্য নতুন কর্মী নিয়োগ হয় না, একই কর্মীরা একটির পর একটি কাজ করেন। পর্ব ১৫-এ POSIX thread দিয়ে একটি thread pool নিজের হাতে বানাবেন।

৮ · Implicit threading — থ্রেড না লিখেও সমান্তরাল

হাতে থ্রেড তৈরি, join আর lock সামলানো কঠিন আর ভুলপ্রবণ। তাই আধুনিক ধারা হলো implicit threading: প্রোগ্রামার বলেন কোন কাজ সমান্তরালে চলতে পারে, আর library বা compiler ঠিক করে কয়টি থ্রেডে, কীভাবে.

লক্ষ করুন, async/await নিজে parallelism দেয় না — এটি concurrency-র কৌশল: এক থ্রেড অপেক্ষার সময়গুলো কাজে লাগায়। হাজার হাজার নেটওয়ার্ক সংযোগের সার্ভারে এটি দারুণ, কারণ বেশিরভাগ সময় সবাই নেটওয়ার্কের অপেক্ষায়; কিন্তু CPU-ভারী হিসাবে এক থ্রেডের event loop আটকে গেলে সব সংযোগ থেমে যায়। তখন worker thread বা আলাদা প্রসেসে হিসাব সরাতে হয়।

৯ · AI-এর যুগে থ্রেড

“C-তে চার থ্রেড দিয়ে একটি অ্যারের যোগফল বের করার কোড দাও” — AI কয়েক সেকেন্ডে দেবে, আর আপনার ল্যাপটপে প্রায়ই ঠিক উত্তরও দেখাবে। Concurrency-র বাগের সবচেয়ে বিপজ্জনক দিক হলো, এরা “আমার মেশিনে চলে” — ভুল ফল আসে লাখে একবার, ভিন্ন core-সংখ্যায়, বা লোড বাড়লে। AI-এর সাধারণ ভুলগুলো:

AI-এর লেখা concurrent কোড ব্যবহারের আগে — চেকলিস্ট

• AI-কে OS, ভাষা ও তার সংস্করণ, core-এর সংখ্যা বলেছি; উত্তর সেই পরিবেশের (POSIX না Win32, কোন JDK বা Python) জন্যই কি না মিলিয়েছি
• প্রতিটি ভাগ করা ভ্যারিয়েবল চিহ্নিত করেছি — কে পড়ে, কে লেখে, কোন lock বা atomic তাকে রক্ষা করে
• প্রোগ্রাম অনেকবার, বিভিন্ন থ্রেড-সংখ্যায় আর লোডের মধ্যে চালিয়েছি; ThreadSanitizer বা Helgrind দিয়ে যাচাই করেছি
• Speedup-এর দাবি নিজে মেপেছি আর Amdahl-এর সূত্রে হাতে মিলিয়েছি; অবাস্তব সংখ্যা মানিনি
• fork, signal বা thread cancellation থাকলে man page-এর নিয়ম (async-signal-safe, cancellation point) মিলিয়েছি
• “sleep দিয়ে ক্রম ঠিক করা”-র মতো কৌশল মানিনি; ক্রম দরকার হলে join, lock বা condition variable ব্যবহার হয়েছে