প্রসেস — state, PCB আর memory layout

১ · প্রোগ্রাম বনাম প্রসেস — রেসিপির খাতা আর চুলায় রান্না

একটি রেস্তোরাঁর রান্নাঘরের কথা ভাবুন। তাকে রাখা আছে রেসিপির একটি খাতা — “কাচ্চি বিরিয়ানি: চাল ধুয়ে নিন, মাংস মেরিনেট করুন, দম দিন…”। খাতাটি নিজে কিছু রান্না করে না। বছরের পর বছর তাকে পড়ে থাকলেও এক দানা ভাতও হবে না। রান্না শুরু হয় যখন একজন বাবুর্চি খাতা খুলে চুলা ধরান, হাঁড়িতে উপকরণ দেন, আর মনে রাখেন “এখন ধাপ ৪-এ আছি, দম শুরু হয়েছে ১০ মিনিট আগে”।

অপারেটিং সিস্টেমে রেসিপির খাতা হলো প্রোগ্রাম — ডিস্কে রাখা একটি ফাইল, যেমন /usr/bin/firefox বা notepad.exe. এতে আছে machine code আর কিছু প্রাথমিক ডেটা। আর চুলায় চলতে থাকা রান্না হলো প্রসেস — চলমান অবস্থায় থাকা একটি প্রোগ্রাম। পাঠ্যবইয়ের ভাষায়: প্রোগ্রাম একটি নিষ্ক্রিয় (passive) জিনিস, আর প্রসেস একটি সক্রিয় (active) জিনিস।

একটি রেসিপি দিয়ে একই সময়ে তিনটি চুলায় তিন হাঁড়ি বিরিয়ানি রান্না হতে পারে — প্রতিটি আলাদা ধাপে। ঠিক তেমনি একটি প্রোগ্রাম থেকে একসাথে অনেক প্রসেস চলতে পারে। আপনি দুটি টার্মিনাল খুললে /bin/bash প্রোগ্রামের দুটি প্রসেস চলে; কোড একই, কিন্তু একটির working directory /home, অন্যটির /tmp, আর তাদের ইতিহাস, ভ্যারিয়েবল ও PID আলাদা। Chrome বা Edge ব্রাউজার একটিমাত্র প্রোগ্রাম, অথচ Task Manager খুললে দেখবেন ডজনখানেক প্রসেস — প্রতিটি ট্যাব বা কাজের জন্য আলাদা।

আরেকটি দিক: একটি প্রসেস চলার মাঝখানে নিজের প্রোগ্রামই বদলে ফেলতে পারে। Unix-এ exec system call ঠিক এটাই করে — PID একই থাকে, কিন্তু ভেতরের কোড বদলে নতুন প্রোগ্রাম বসে। তাই “প্রসেস = প্রোগ্রাম” নয়; প্রসেস হলো একটি চলমান কাজের পুরো প্রেক্ষাপট, যার ভেতরে এই মুহূর্তে কোনো একটি প্রোগ্রামের কোড চলছে। (fork, exec আর wait নিয়ে বিস্তারিত পর্ব ১০-এ।)

২ · প্রসেসের মেমরি — text, data, BSS, heap আর stack

প্রতিটি প্রসেস মনে করে, পুরো একটি মেমরি তার একার। এই নিজস্ব ঠিকানার জগৎকে বলে address space. আসলে virtual memory-র কৌশলে OS প্রতিটি প্রসেসকে আলাদা “মানচিত্র” দেয় (পর্ব ৩০ ও ৩৫)। সেই মানচিত্রে জিনিসপত্র একটি নির্দিষ্ট নিয়মে সাজানো। x86-64 Linux-এ সাধারণ একটি প্রসেসের address space নিচ থেকে ওপরে মোটামুটি এরকম:

  high addresses
 ┌──────────────────────────┐
 │ kernel space             │  সব প্রসেসে একই; user mode থেকে ছোঁয়া নিষেধ
 ├──────────────────────────┤  <- 0x00007fffffffffff (user অংশের শেষ)
 │ [vvar] [vdso]            │  kernel-এর দেওয়া ছোট library (পর্ব ৫)
 │ stack        (grows v)   │  লোকাল ভ্যারিয়েবল, প্রতি কলে একটি frame
 │                          │
 │     ... free space ...   │
 │                          │
 │ mmap area    (grows v)   │  shared library (libc.so), বড় malloc
 │                          │
 │     ... free space ...   │
 │                          │
 │ heap         (grows ^)   │  malloc / new দিয়ে নেওয়া মেমরি
 ├──────────────────────────┤
 │ BSS                      │  শূন্য বা মানহীন global / static
 │ data                     │  মান দেওয়া global / static
 │ text                     │  machine code (পড়া + চালানো, লেখা নয়)
 └──────────────────────────┘
  low addresses

কয়েকটি বিষয় খেয়াল করার মতো। BSS নামটি এসেছে পুরোনো একটি assembler directive থেকে — “Block Started by Symbol”. এর চালাকিটা হলো: যে ডেটার সব মান শূন্য, তা প্রোগ্রাম ফাইলে লিখে রাখার দরকার নেই; ফাইলে শুধু লেখা থাকে “এত বাইট শূন্য লাগবে”, আর প্রসেস তৈরির সময় OS শূন্য-ভরা মেমরি দিয়ে দেয়। একটু পরে নিজেই মেপে দেখবেন।

Heap আর stack মুখোমুখি বাড়ে — heap নিচ থেকে ওপরে, stack ওপর থেকে নিচে। মাঝে বিশাল ফাঁকা এলাকা, যাতে দুজনেই নিজের মতো বাড়তে পারে। Stack-এর একটি সীমা থাকে: Linux-এ মূল thread-এর জন্য সাধারণত ৮ MB (ulimit -s দেখায় 8192), Windows-এ MSVC-র ডিফল্ট ১ MB. অসীম recursion করলে stack সেই সীমা পেরিয়ে যায় — Linux-এ ফল “Segmentation fault”, Windows-এ “stack overflow” exception.

নিজের চোখে ক্রম যাচাই

নিচের C প্রোগ্রামে প্রতিটি অংশ থেকে একটি করে জিনিস নেওয়া হয়েছে: একটি ফাংশন, একটি মান দেওয়া global, একটি static, একটি মানহীন global, একটি malloc ব্লক আর একটি লোকাল ভ্যারিয়েবল। প্রোগ্রামটি সবার ঠিকানা নিয়ে ছোট থেকে বড় ক্রমে সাজায়, আর শুধু নামগুলো ছাপে। কাঁচা ঠিকানা ছাপা হয়নি ইচ্ছে করেই — কেন, তা একটু পরে বুঝবেন।

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
int global_init = 42;                /* initialised global -> data */
int global_zero;                     /* zero global        -> BSS  */
static int counter = 7;              /* static variable    -> data */
struct item { const char *name; uintptr_t addr; };

static int by_addr(const void *x, const void *y) {
    const struct item *a = x, *b = y;
    return (a->addr > b->addr) - (a->addr < b->addr);
}
int main(void) {
    int local = 1;                           /* local variable -> stack */
    int *heap = malloc(sizeof *heap);        /* malloc block   -> heap  */
    struct item v[] = {
        { "stack : local",        (uintptr_t)&local },
        { "heap  : malloc block", (uintptr_t)heap },
        { "bss   : global_zero",  (uintptr_t)&global_zero },
        { "data  : global_init",  (uintptr_t)&global_init },
        { "data  : static counter", (uintptr_t)&counter },
        { "text  : function main",  (uintptr_t)&main },
    };
    int n = sizeof v / sizeof v[0];
    qsort(v, n, sizeof v[0], by_addr);
    printf("sorted from LOW address to HIGH address:\n");
    for (int i = 0; i < n; i++) printf("  %d. %s\n", i + 1, v[i].name);
    uintptr_t gap = (uintptr_t)&local - (uintptr_t)heap;
    printf("heap-to-stack gap > 1 GiB? %s\n", gap > (1UL << 30) ? "yes" : "no");
    printf("values: %d %d %d\n", global_init, global_zero, counter);
    free(heap);
    return 0;
}

sorted from LOW address to HIGH address:
  1. text  : function main
  2. data  : global_init
  3. data  : static counter
  4. bss   : global_zero
  5. heap  : malloc block
  6. stack : local
heap-to-stack gap > 1 GiB? yes
values: 42 0 7

ASLR — ঠিকানা কেন প্রতিবার বদলায়

উপরের প্রোগ্রামে ঠিকানাগুলো ছাপলে প্রতিবার আলাদা সংখ্যা দেখতেন। কারণ আধুনিক OS ইচ্ছে করে প্রতিটি প্রসেসের stack, heap, mmap এলাকা আর (PIE প্রোগ্রামে) text-এর শুরুর ঠিকানা এলোমেলো করে দেয়। একে বলে ASLR (address space layout randomization). উদ্দেশ্য প্রতিরক্ষামূলক: কোনো বাগ কাজে লাগিয়ে আক্রমণকারী যদি নির্দিষ্ট ঠিকানায় লাফ দিতে চায়, সে ঠিকানাটি আগে থেকে জানবে না। লক্ষ করুন, ASLR ঠিকানা বদলায়, ক্রম নয় — তাই উপরের প্রোগ্রাম প্রতিবার একই ক্রম ছাপে। Linux-এ /proc/sys/kernel/randomize_va_space ফাইলে 2 মানে পূর্ণ ASLR চালু; Windows-এ Vista (২০০৭) থেকে ASLR আছে। নিরাপত্তার দিক থেকে ASLR-এর শক্তি আর সীমা নিয়ে বিস্তারিত পর্ব ৪৮-এ।

চলার সময় heap আর stack কীভাবে বাড়ে-কমে

এবার একটি ছোট প্রোগ্রাম ধাপে ধাপে চালাই। ঠিকানাগুলো বোঝার সুবিধার জন্য ছোট করে বানানো (আসল ঠিকানা অনেক বড়, আর malloc প্রতিটি ব্লকের সাথে কিছু হিসাবের বাইট রাখে — এখানে সেটি বাদ দেওয়া হয়েছে)। Stack pointer (SP) আর heap-এর ব্যবহৃত সীমা কীভাবে বদলায়, খেয়াল করুন:

1int main(void) {2    char *p = malloc(100);3    f(1);4    return 0;5}6void f(int n) {7    int x = n;8    g();9}10void g(void) {11    char *q = malloc(4000);12    free(q);13}

শেষ ধাপের শিক্ষাটি গুরুত্বপূর্ণ: stack-এর মেমরি ফাংশন ফিরলেই নিজে থেকে ফেরত যায়; heap-এর মেমরি প্রোগ্রামারকে নিজে ফেরত দিতে হয় (C-তে free, অথবা Java, Python-এর মতো ভাষায় garbage collector). একটি ভুল ধারণাও এখানে দূর করে নিন: প্রসেসের “heap” আর ডেটা স্ট্রাকচারের heap (priority queue) সম্পূর্ণ আলাদা জিনিস — শুধু নামের মিল।

BSS কেন ফাইলে জায়গা নেয় না — মেপে দেখুন

নিচের bash স্ক্রিপ্ট তিনটি ছোট C প্রোগ্রাম বানিয়ে compile করে: একটিতে কিছু নেই, একটিতে ১ MB-র শূন্য অ্যারে, আর একটিতে একই ১ MB অ্যারে, তবে প্রথম ঘরে 1. তারপর size কমান্ড দিয়ে প্রতিটির text, data আর BSS-এর আকার, আর stat দিয়ে ডিস্কে ফাইলের আকার দেখায়:

# three tiny programs: the same 1 MB array, placed differently
cat > none.c <<'EOF'
int main(void) { return 0; }
EOF
cat > zero.c <<'EOF'
int big[262144];                    /* 1 MB of zeros   -> BSS  */
int main(void) { return big[0]; }
EOF
cat > init.c <<'EOF'
int big[262144] = {1};              /* 1 MB, one non-zero -> data */
int main(void) { return big[0]; }
EOF
for p in none zero init; do gcc -O0 -o "$p" "$p.c"; done
echo "== size: text, data and bss of each program (bytes) =="
size none zero init | awk '{printf "%-8s %-8s %-9s %s\n", $1, $2, $3, $6}'
echo
echo "== file size on disk (bytes) =="
for p in none zero init; do printf "%-5s %s\n" "$p" "$(stat -c %s "$p")"; done

== size: text, data and bss of each program (bytes) ==
text     data     bss       filename
1228     544      8         none
1229     544      1048608   zero
1229     1049136  8         init

== file size on disk (bytes) ==
none  15776
zero  15808
init  1064400

৩ · প্রসেসের পাঁচ অবস্থা — new থেকে terminated

একটি প্রসেস সারাক্ষণ CPU-তে চলে না। একটি সাধারণ কম্পিউটারে একসাথে কয়েকশো প্রসেস থাকে, অথচ CPU core হয়তো চার বা আটটি। তাই যেকোনো মুহূর্তে বেশিরভাগ প্রসেস হয় নিজের পালার অপেক্ষায়, নয়তো কোনো ঘটনার অপেক্ষায় (কিবোর্ডে চাপ, ডিস্ক থেকে ডেটা, নেটওয়ার্কের প্যাকেট)। প্রসেস এখন কোন দশায় আছে, তাকে বলে process state. পাঠ্যবইয়ের সবচেয়ে প্রচলিত মডেলে অবস্থা পাঁচটি:

           admit               dispatch                exit
 ┌─────┐ ---------> ┌───────┐ ------------> ┌─────────┐ ------> ┌────────────┐
 │ new │            │ ready │               │ running │         │ terminated │
 └─────┘            └───────┘ <------------ └─────────┘         └────────────┘
                        ^       timeout or       │
                        │       interrupt        │ I/O or
                        │                        │ event wait
                        │      ┌─────────┐       │
                        └───── │ waiting │ <─────┘
                 I/O or event  └─────────┘
                     done

প্রতিটি তীরের সঠিক কারণ

পরীক্ষায় শুধু অবস্থার নাম নয়, প্রতিটি transition কেন ঘটে আর কে ঘটায়, তা জানতে চাওয়া হয়। মোট ছয়টি বৈধ তীর:

নিচের ডায়াগ্রামে একটি প্রসেস P-এর (ধরা যাক একটি গান বাজানোর অ্যাপ) পুরো জীবন দেখুন। সাথে আরেকটি প্রসেস Q আছে, আর CPU একটিই। প্রতিটি ধাপে কোন ঘটনা ঘটল, আর queue-গুলো কীভাবে বদলাল খেয়াল করুন:

1shell: fork() + exec("player")2kernel: setup done -> admit P3scheduler: pick P (dispatch)4timer interrupt: P's slice over5scheduler: pick P again6P: read(fd, buf, 4096) from disk7disk interrupt: data ready8scheduler: pick P9P: exit(0)

এবার একই নিয়ম একটি ছোট সিমুলেটরে চালিয়ে দেখুন। কোডটি তিনটি প্রসেস A, B, C-এর জন্য ঘটনার একটি তালিকা প্রক্রিয়া করে, প্রতিটি ঘটনার পর state-এর টেবিল ছাপে, আর অবৈধ ঘটনা প্রত্যাখ্যান করে — যেমন waiting প্রসেসকে dispatch করা, বা CPU ব্যস্ত থাকতে আরেকজনকে running করা (এক CPU ধরে):

// legal transitions of the 5-state model: event -> [from, to]
const RULES = {
  admit:    ['new', 'ready'],         dispatch: ['ready', 'running'],
  timeout:  ['running', 'ready'],     io_wait:  ['running', 'waiting'],
  io_done:  ['waiting', 'ready'],     exit:     ['running', 'terminated'],
};
const state = {}, used = {};            // pid -> state, event -> count
const events = [
  'create A', 'create B', 'create C', 'admit A', 'admit B', 'dispatch A',
  'admit C', 'io_wait A', 'dispatch A', 'dispatch B', 'io_done A',
  'dispatch A', 'timeout B', 'dispatch A', 'exit A', 'dispatch C',
  'io_wait C', 'dispatch B', 'exit B', 'io_done C', 'dispatch C', 'exit C',
];
const pad = s => s.padEnd(11);
console.log((pad('event') + pad('A') + pad('B') + 'C'));
for (const ev of events) {
  const [what, p] = ev.split(' ');
  let note = '';
  if (what === 'create') state[p] = 'new';
  else {
    const [from, to] = RULES[what];
    const busy = Object.keys(state).find(q => state[q] === 'running');
    if (state[p] !== from) note = `  REJECTED: ${p} is ${state[p]}, not ${from}`;
    else if (to === 'running' && busy) note = `  REJECTED: CPU busy with ${busy}`;
    else { state[p] = to; used[what] = (used[what] || 0) + 1; }
  }
  console.log((pad(ev) + ['A', 'B', 'C'].map(q => pad(state[q] || '-')).join('')).trimEnd() + note);
}
console.log('accepted: ' + Object.entries(used).map(([e, n]) => `${e} x${n}`).join(', '));

event      A          B          C
create A   new        -          -
create B   new        new        -
create C   new        new        new
admit A    ready      new        new
admit B    ready      ready      new
dispatch A running    ready      new
admit C    running    ready      ready
io_wait A  waiting    ready      ready
dispatch A waiting    ready      ready  REJECTED: A is waiting, not ready
dispatch B waiting    running    ready
io_done A  ready      running    ready
dispatch A ready      running    ready  REJECTED: CPU busy with B
timeout B  ready      ready      ready
dispatch A running    ready      ready
exit A     terminated ready      ready
dispatch C terminated ready      running
io_wait C  terminated ready      waiting
dispatch B terminated running    waiting
exit B     terminated terminated waiting
io_done C  terminated terminated ready
dispatch C terminated terminated running
exit C     terminated terminated terminated
accepted: admit x3, dispatch x6, io_wait x2, io_done x2, timeout x1, exit x3

৪ · Suspended অবস্থা — ৭-state model

পাঁচ অবস্থার মডেল ধরে নেয়, সব প্রসেস সবসময় RAM-এ থাকে। কিন্তু RAM ফুরিয়ে গেলে? ধরুন অনেকগুলো প্রসেস waiting অবস্থায় RAM দখল করে বসে আছে, আর নতুন প্রসেস চালানোর জায়গা নেই। পুরোনো সিস্টেমগুলোর সমাধান ছিল swapping: কিছু প্রসেসের পুরো মেমরি ডিস্কের swap এলাকায় সরিয়ে দেওয়া। এমন প্রসেসকে বলে suspended — সে আছে, কিন্তু RAM-এ নেই, তাই চলতে পারে না। এ জন্য William Stallings-এর পাঠ্যবইসহ অনেক বইয়ে দুটি নতুন অবস্থা যোগ করে ৭-state model দেখানো হয়:

                  IN RAM                              ON DISK (suspended)
             ┌───────────┐     suspend ------>      ┌─────────────────┐
 not waiting │   ready   │                          │  ready/suspend  │
             └───────────┘     <------ activate     └─────────────────┘
                   ^                                         ^
      event occurs │                                         │ event occurs
                   │                                         │
             ┌───────────┐     suspend ------>      ┌─────────────────┐
 waiting     │  blocked  │                          │ blocked/suspend │
             └───────────┘     <------ activate     └─────────────────┘

 plus the 5-state arrows: new -> ready (or new -> ready/suspend when RAM is short),
 ready <-> running, running -> blocked, running -> terminated

ছবিটি জটিল দেখালেও মূল কথা সহজ। দুটি প্রশ্ন আলাদা করে ভাবুন: (১) প্রসেস কি কোনো ঘটনার অপেক্ষায়? (২) প্রসেস কি RAM-এ আছে? দুই প্রশ্নের চার রকম উত্তর থেকে চারটি অবস্থা:

নতুন transition-গুলো:

• blocked → blocked/suspend (suspend): RAM-এর চাপ হলে OS সবচেয়ে আগে অপেক্ষারত প্রসেস সরায় — সে তো এমনিতেও চলছে না।
• blocked/suspend → ready/suspend (event occurs): ডিস্কে থাকা অবস্থাতেই তার অপেক্ষার ঘটনা ঘটে গেল। এখন সে প্রস্তুত, শুধু RAM-এ ফেরা বাকি।
• ready/suspend → ready (activate): RAM খালি হলে OS তাকে ফিরিয়ে আনে।
• ready → ready/suspend (suspend): অনেক বড় একটি প্রসেসের জায়গা করতে বা অনেক কম অগ্রাধিকারের প্রসেস সরাতে, ready প্রসেসকেও সরানো হতে পারে।
• new → ready/suspend (admit): RAM কম থাকলে নতুন প্রসেস সরাসরি ডিস্কেই রাখা হয়।
• blocked/suspend → blocked (activate): বিরল — OS যদি মনে করে ঘটনাটি শিগগিরই ঘটবে আর প্রসেসটি গুরুত্বপূর্ণ। কিছু বইয়ে running → ready/suspend তীরও থাকে।

৫ · PCB — প্রসেসের পরিচয়পত্র, আর Linux-এর task_struct

Timer interrupt-এ P থেমে গেল, পরে আবার ঠিক সেখান থেকেই চলল — কীভাবে? কারণ kernel প্রতিটি প্রসেসের জন্য একটি তথ্যের রেকর্ড রাখে: process control block (PCB). প্রসেস সম্পর্কে kernel যা জানে, সব এখানে বা এখান থেকে যুক্ত অন্য struct-এ।

পাঠ্যবই (Silberschatz-দের Operating System Concepts) PCB-র উপাদানগুলো এভাবে তালিকা করে — পরীক্ষায় এই তালিকাটি প্রায় হুবহু চাওয়া হয়:

PCB-র আসল পরীক্ষা হয় context switch-এর সময়: এক প্রসেসের register PCB-তে সংরক্ষণ, আরেকটির PCB থেকে register ফিরিয়ে আনা। পরের পর্বে (পর্ব ৯) এর খরচ আর CPU-স্তরের খুঁটিনাটি দেখবেন; এখানে শুধু দেখুন কোন ঘর কখন বদলায়। ঠিকানাগুলো ছোট করে বানানো:

1P1 running in user mode2timer interrupt -> kernel3save P1 registers -> PCB(P1)4PCB(P1): state, CPU time, queue5scheduler picks P26load PCB(P2) -> CPU, to user mode7P2: read() -> waiting; P1 back

বাস্তবের PCB — xv6 আর Linux

MIT-র শিক্ষণ-OS xv6-এ (পর্ব ৫৮) PCB-র নাম struct proc, আর সেটি এতই ছোট যে পুরোটা পড়া যায়। Linux-এ একই কাজ করে task_struct, যা include/linux/sched.h ফাইলে কয়েকশো লাইনের একটি struct. নিচে দুটো পাশাপাশি দেখুন:

enum procstate { UNUSED, USED, SLEEPING, RUNNABLE, RUNNING, ZOMBIE };

// Per-process state
struct proc {
  struct spinlock lock;

  // p->lock must be held when using these:
  enum procstate state;        // Process state
  void *chan;                  // If non-zero, sleeping on chan
  int killed;                  // If non-zero, have been killed
  int xstate;                  // Exit status to be returned to parent's wait
  int pid;                     // Process ID

  // wait_lock must be held when using this:
  struct proc *parent;         // Parent process

  // these are private to the process, so p->lock need not be held.
  uint64 kstack;               // Virtual address of kernel stack
  uint64 sz;                   // Size of process memory (bytes)
  pagetable_t pagetable;       // User page table
  struct trapframe *trapframe; // data page for trampoline.S
  struct context context;      // swtch() here to run process
  struct file *ofile[NOFILE];  // Open files
  struct inode *cwd;           // Current directory
  char name[16];               // Process name (debugging)
};

struct task_struct {
    unsigned int          __state;    /* TASK_RUNNING, TASK_INTERRUPTIBLE, ... */
    void                 *stack;      /* this task's kernel stack */
    int                   prio, static_prio;   /* priority; nice maps here */
    unsigned int          policy;     /* SCHED_NORMAL, SCHED_FIFO, ... */
    struct sched_entity   se;         /* fair-scheduler bookkeeping */
    struct mm_struct     *mm;         /* address space: page tables, areas */
    pid_t                 pid;        /* id of this task (thread) */
    pid_t                 tgid;       /* thread group id = what getpid() returns */
    struct task_struct __rcu *real_parent;  /* who created us */
    struct list_head      children;   /* our children */
    struct list_head      sibling;    /* link in parent's children list */
    u64                   utime, stime;     /* CPU time: user / kernel mode */
    unsigned long         nvcsw, nivcsw;    /* voluntary / involuntary switches */
    char                  comm[TASK_COMM_LEN];  /* name, 16 bytes */
    struct fs_struct     *fs;         /* root and current directory */
    struct files_struct  *files;      /* open file table */
    struct signal_struct *signal;     /* signal state shared by threads */
    /* ... many more fields ... */
    struct thread_struct  thread;     /* CPU-specific state: saved sp, ... */
};

পাঠ্যবইয়ের তালিকার সাথে মিলিয়ে নিন। State: xv6-এর state, Linux-এর __state (Linux 5.14-এর আগে নাম ছিল state). PID ও parent: pid, parent / real_parent. Register: xv6-এ trapframe (user mode-এর register) আর context (kernel-এর ভেতরে switch-এর register); Linux-এ user register থাকে প্রসেসের kernel stack-এ, আর thread-এ kernel-এর stack pointer-এর মতো জিনিস। মেমরি: xv6-এর pagetable ও sz, Linux-এর mm. I/O: xv6-এর ofile অ্যারে, Linux-এর files. Accounting: Linux-এর utime, stime, আর nvcsw/nivcsw — যা পর্ব ৫-এ /proc/self/status-এ voluntary আর nonvoluntary context switch হিসেবে দেখেছিলেন।

একটি সূক্ষ্ম কথা: Linux-এ প্রসেস আর thread দুটোই একই task_struct দিয়ে চলে। প্রতিটি thread-এর নিজের pid, কিন্তু একই প্রসেসের সব thread-এর tgid এক — আর getpid() ফেরত দেয় সেই tgid. একই প্রসেসের thread-গুলো একটি mm আর একটি files ভাগ করে। Windows-এ ব্যবস্থাটি আলাদা: প্রসেসের জন্য EPROCESS, প্রতিটি thread-এর জন্য আলাদা ETHREAD struct, আর scheduling হয় thread ধরে (পর্ব ৫৬)।

৬ · Process queue আর তিন রকম scheduler

PCB-গুলো kernel-এর মেমরিতে এলোমেলো পড়ে থাকে না; অবস্থা অনুযায়ী বিভিন্ন queue বা তালিকায় যুক্ত থাকে (সাধারণত PCB-র ভেতরের একটি link ঘর দিয়ে, যেমন একটি linked list). ক্লাসিক পাঠ্যবইয়ে তিন রকম queue:

• Job queue: সিস্টেমের সব প্রসেস — পুরোনো batch সিস্টেমে ডিস্কে জমা থাকা, চালানোর অপেক্ষায় থাকা কাজও।
• Ready queue: যারা RAM-এ আছে আর চলার জন্য প্রস্তুত। ব্যাংকের টোকেন-কাউন্টারের সামনের সারি।
• Device queue (wait queue): প্রতিটি ডিভাইস বা ঘটনার জন্য আলাদা সারি — ডিস্কের queue, কিবোর্ডের queue, নেটওয়ার্ক socket-এর queue. ঘটনা ঘটলে kernel সেই queue-র প্রসেসদের ready queue-তে পাঠায়।

 new process --> [ ready queue ] --dispatch--> ( CPU ) --exit--> done
                    ^  ^  ^  ^                     │
                    │  │  │  └───── timeout <──────┤
                    │  │  └─ [ disk queue ]  <─────┤ read() / write()
                    │  └──── [ child-exit wait ] <─┤ wait()
                    └─────── [ sleep / timer ] <───┘ sleep()

কোন queue থেকে কে কখন অন্য জায়গায় যাবে, সেই সিদ্ধান্ত নেয় scheduler. ক্লাসিক বইয়ে তিন স্তরের scheduler:

আজকের Linux, Windows বা macOS-এর মতো time-sharing সিস্টেমে আলাদা long-term scheduler প্রায় নেই: আপনি প্রোগ্রাম চালালেই সেটি সরাসরি ready হয়। লোড সামলানোর কাজটি এখন ব্যবহারকারী (বেশি ধীর লাগলে কিছু বন্ধ করেন), সার্ভারের job queue (যেমন HPC ক্লাস্টারের Slurm), বা container-এর সীমা (cgroup, পর্ব ২১ ও ৫১) করে। Medium-term-এর কাজটি ঘটে page ধরে ধরে memory management-এর ভেতরে। কিন্তু short-term scheduler সবখানেই আছে, আর এটিই মডিউল ৩-এর মূল বিষয়। Linux-এ প্রতিটি CPU-র নিজের একটি run queue থাকে (ready queue-র বাস্তব রূপ), আর অপেক্ষার জন্য kernel-এর নানা জায়গায় wait_queue.

৭ · প্রসেসের পরিবার — parent, child আর PID 1

Unix-ধরনের সিস্টেমে প্রতিটি প্রসেস তৈরি করে আরেকটি প্রসেস। যে তৈরি করে সে parent, যাকে তৈরি করা হলো সে child. ফলে সব প্রসেস মিলে একটি গাছ (process tree). গাছের শিকড়ে PID 1 — বুটের সময় kernel যে প্রথম user-space প্রোগ্রাম চালায় (init; আজকের বেশিরভাগ Linux-এ systemd, macOS-এ launchd; পর্ব ৭)। Kernel-এর নিজের কাজের জন্য থাকে kernel thread — Linux-এ তাদের অভিভাবক kthreadd, যার PID সাধারণত 2.

$ pstree -p        (উদাহরণ আউটপুট, ছোট করে দেখানো)
systemd(1)─┬─sshd(812)───sshd(3301)───bash(3307)───pstree(3420)
           ├─cron(640)
           ├─NetworkManager(598)─┬─{NetworkManager}(611)
           │                     └─{NetworkManager}(613)
           └─systemd-journal(301)

পড়ার নিয়ম: pstree নিজে child of bash, bash child of sshd (দূর থেকে লগইন), আর সবার শিকড় systemd (1). কোঁকড়া বন্ধনীর {NetworkManager} হলো একই প্রসেসের thread. দুটি বিশেষ ঘটনা পরীক্ষায় আর বাস্তবে দুই জায়গাতেই গুরুত্বপূর্ণ:

Windows-এ ব্যবস্থাটি একটু আলাদা। প্রতিটি প্রসেস তৈরির সময় parent-এর PID লেখা থাকে, কিন্তু kernel কোনো কঠোর গাছ রক্ষা করে না: parent শেষ হলে child-কে কারও কাছে হস্তান্তর করা হয় না, আর Unix-এর মতো zombie অবস্থাও নেই (প্রসেস object থাকে যতক্ষণ কেউ তার handle খোলা রাখে)। Windows-এ PID 4 হলো “System” প্রসেস, যার ভেতরে kernel-এর thread চলে, আর PID 0 “System Idle Process”.

৮ · Linux আর Windows-এ প্রসেস চোখে দেখা

Linux-এ প্রতিটি প্রসেসের জন্য /proc/<pid>/ নামের একটি ফোল্ডার থাকে — kernel পড়ার মুহূর্তে এর “ফাইল”গুলো PCB থেকে তৈরি করে দেয় (procfs). status ফাইলে state, PID, parent, মেমরি; maps ফাইলে address space-এর প্রতিটি এলাকা। আর ps কমান্ড এগুলোই পড়ে সুন্দর করে দেখায়। কিন্তু আগে একটি গুরুত্বপূর্ণ টেবিল — Linux kernel পাঠ্যবইয়ের নামগুলো কোন অক্ষরে দেখায়:

প্রথম সারিটি সবচেয়ে চমকপ্রদ: Linux ready আর running আলাদা করে না; দুটোই R, ভেতরে TASK_RUNNING. কে এই মুহূর্তে আসলে CPU-তে, তা বোঝা যায় শুধু প্রতিটি CPU-র “current” প্রসেস দেখে। ps-এর STAT কলামে মূল অক্ষরের পর আরও কিছু চিহ্ন বসতে পারে: s = session leader, N = কম অগ্রাধিকার (nice), < = বেশি অগ্রাধিকার, l = multi-threaded, + = টার্মিনালের foreground দলে।

এবার এই পাতার Linux রানারে সব একসাথে দেখি: নিজের state, নিজের মেমরির এলাকা, আর পটভূমিতে ঘুমিয়ে থাকা একটি প্রসেস:

echo "== /proc/self/status (self = grep) =="
grep -E '^(Name|State|Pid|PPid|Threads)' /proc/self/status
echo
echo "== segments in /proc/self/maps, low to high (self = awk) =="
awk '$6 ~ /awk$/ && $2 ~ /x/  {print "text  ", $2, $6}
     $6 == "[heap]"           {print "heap  ", $2, $6}
     $6 == "[stack]"          {print "stack ", $2, $6}
     $6 == "[vdso]"           {print "vdso  ", $2, $6}' /proc/self/maps
echo
echo "== a sleeping background process =="
sleep 2 &
sleep 0.2
ps -o pid,ppid,stat,cmd
echo
echo "shell PID \$\$ = $$, background sleep PID \$! = $!"
kill $!
wait $! 2>/dev/null      # hide bash "Terminated" notice
echo "after kill: exit status $? (128 + 15 = SIGTERM)"

== /proc/self/status (self = grep) ==
Name:	grep
State:	R (running)
Pid:	3
PPid:	2
Threads:	1

== segments in /proc/self/maps, low to high (self = awk) ==
text   r-xp /usr/bin/mawk
heap   rw-p [heap]
stack  rw-p [stack]
vdso   r-xp [vdso]

== a sleeping background process ==
    PID    PPID STAT CMD
      1       0 SNs  /run/podman-init -- /bin/bash prog.sh
      2       1 SN   /bin/bash prog.sh
      5       2 SN   sleep 2
      7       2 RN   ps -o pid,ppid,stat,cmd

shell PID $$ = 2, background sleep PID $! = 5
after kill: exit status 143 (128 + 15 = SIGTERM)

নিজের Linux মেশিনে আরও কিছু কাজের কমান্ড (এই পাতায় চালানোর দরকার নেই; আপনার মেশিনে আউটপুট আলাদা হবে):

ps -eo pid,ppid,stat,cmd --forest | head -20   # every process, as a tree
ps -eo pid,ppid,stat,cmd | awk '$3 ~ /^Z/'     # find zombies
ps -eo pid,stat,wchan:20,cmd | awk '$2 ~ /^D/' # who is stuck in D, and where
cat /proc/1/status | head -8                   # PID 1's PCB, as text
cat /proc/$$/maps                              # this shell's memory map

Windows-এ: Task Manager আর PowerShell

Windows-এ Ctrl+Shift+Esc চেপে Task Manager খুলুন, তারপর Details ট্যাব। সেখানে PID, Status (Running বা Suspended), User name, CPU আর Memory কলাম দেখবেন; কলামের শিরোনামে ডান-ক্লিক করে আরও কলাম (যেমন Threads, Handles) যোগ করা যায়। Windows-এ scheduling হয় thread ধরে, তাই প্রসেসের “Running” মানে তার অন্তত একটি thread চলার উপযুক্ত — Linux-এর মতো R/S/D অক্ষর এখানে নেই। PowerShell-এ একই তথ্য (উদাহরণ আউটপুট, আপনার মেশিনে সংখ্যা আলাদা):

PS> Get-Process -Name notepad, explorer | Select-Object Id, ProcessName, CPU, @{n='Threads';e={$_.Threads.Count}}

   Id ProcessName       CPU Threads
   -- -----------       --- -------
 6140 explorer      152.375      96
 9212 notepad         0.531       8

PS> Get-CimInstance Win32_Process -Filter "Name='notepad.exe'" | Select-Object ProcessId, ParentProcessId, Name

ProcessId ParentProcessId Name
--------- --------------- ----
     9212            6140 notepad.exe

দ্বিতীয় কমান্ড দেখাচ্ছে notepad-এর parent হলো explorer (৬১৪০) — Start মেনু বা ডেস্কটপ থেকে চালালে এমনই হয়। পুরোনো Windows PowerShell 5.1-এ Get-Process parent দেখায় না, তাই Win32_Process লাগে; PowerShell 7-এ (Get-Process notepad).Parent দিয়েও পাওয়া যায়। Sysinternals-এর Process Explorer প্রসেসগুলো গাছ আকারে দেখায় — Windows-এর pstree বলতে পারেন।

৯ · AI-এর যুগে প্রসেস নিয়ে কাজ

“সার্ভার ধীর, কোন প্রসেস দায়ী?” বা “zombie প্রসেস কীভাবে মুছব?” — AI চটপট কমান্ড দেবে। অনেক সময় ঠিকও হবে। কিন্তু এই বিষয়ে AI-এর ভুলগুলো বেশ নির্দিষ্ট, আর এই পর্বের ধারণা থাকলে আপনি সেগুলো ধরতে পারবেন:

AI-এর প্রসেস-সংক্রান্ত পরামর্শ মানার আগে — চেকলিস্ট

• AI-কে OS, distro, kernel-এর সংস্করণ আর shell জানিয়েছি; উত্তরের কমান্ড সেই OS-এরই কি না দেখেছি
• প্রতিটি STAT অক্ষরের ব্যাখ্যা man ps আর man 5 proc-এ মিলিয়েছি
• কোনো প্রসেস বন্ধ করার আগে ps -o pid,ppid,stat,cmd দিয়ে নিশ্চিত হয়েছি এটি ঠিক প্রসেস, আর আগে সাধারণ kill (SIGTERM) দিয়েছি
• ঠিকানা বা PID নিয়ে কোনো দাবি একাধিকবার চালিয়ে যাচাই করেছি; ASLR-এ ঠিকানা বদলায়
• state diagram বা PCB নিয়ে AI-এর উত্তর পাঠ্যবইয়ের সংজ্ঞার সাথে মিলিয়েছি — যেমন waiting → running তীর আঁকলে সেটি ভুল
• sudo, chmod 777 বা নিরাপত্তা-সেটিং (যেমন ASLR) বন্ধ করার পরামর্শ মানিনি