thread, process আর GIL — একসাথে অনেক কাজ (free-threaded Python)

১ · একসাথে অনেক কাজ — concurrency বনাম parallelism

আগের পর্বে আপনি ডিবাগিং আর logging শিখেছেন — প্রোগ্রাম ঠিকমতো চলছে কি না, তা দেখার কৌশল। এবার প্রশ্ন বদলাচ্ছে: প্রোগ্রাম ঠিক চলছে, কিন্তু ধীর. ধরুন আপনার একটি স্ক্রিপ্ট ১০টি ওয়েবসাইট থেকে খবর আনে। প্রতিটি সাইট উত্তর দিতে এক সেকেন্ড নেয়। একটার পর একটা আনলে লাগে ১০ সেকেন্ড। অথচ এই ১০ সেকেন্ডের প্রায় পুরোটাই আপনার কম্পিউটার কিছুই করছে না — শুধু অপেক্ষা করছে, কখন উত্তর আসবে।

এই অপেক্ষার সময়টা কাজে লাগানোর বিদ্যাই এই পর্বের বিষয়। শুরুতে দুটি শব্দের পার্থক্য পরিষ্কার করা দরকার, কারণ অনেকে এদের একই মনে করেন।

কোন কাজ কীসের জন্য অপেক্ষা করে — I/O-bound বনাম CPU-bound

কোন পদ্ধতি কাজে আসবে, তা নির্ভর করে আপনার কাজটি কোথায় সময় খরচ করছে, তার ওপর। এটাই এই পর্বের সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন।

I/O-bound কাজে CPU বসে থাকে, তাই একজন কর্মীও পালা করে অনেক কাজ এগিয়ে নিতে পারে — concurrency যথেষ্ট। CPU-bound কাজে CPU এক মুহূর্তও বসে নেই; এটা দ্রুত করতে হলে কাজ ভাগ করে একাধিক core-এ একসাথে চালাতে হয় — parallelism লাগে।

২ · thread — একই প্রোগ্রামের ভেতরে একাধিক কর্মী

আপনি যখন python app.py চালান, operating system একটি process তৈরি করে — নিজস্ব মেমরি, নিজস্ব ফাইল-হ্যান্ডেল সহ একটি চলমান প্রোগ্রাম। শুরুতে তার ভেতরে একটিই কাজের ধারা থাকে, যাকে বলে main thread. একটি thread হলো process-এর ভেতরের একটি স্বাধীন কাজের ধারা। একই process-এর সব thread একই মেমরি ভাগ করে — একই ভ্যারিয়েবল, একই list, একই dict দেখে। এটাই thread-এর সুবিধা (ডেটা দেওয়া-নেওয়া সহজ), আবার বিপদও (একসাথে বদলালে গোলমাল, অংশ ৪-এ)।

Python-এর standard library-তে আছে threading module. সবচেয়ে মৌলিক ব্যবহার দেখুন — তিনটি পাতা “নামানো”-র কাজ তিনটি thread-এ:

import threading

def download(page, results):
    results[page] = f"{page}: পাতা এসেছে"   # আসলে নেটওয়ার্কের কাজ

pages = ["home", "news", "sports"]
results = {}
threads = [threading.Thread(target=download, args=(p, results)) for p in pages]
for t in threads:
    t.start()        # thread চালু — কাজ শুরু
for t in threads:
    t.join()         # শেষ হওয়া পর্যন্ত অপেক্ষা
for p in pages:
    print(results[p])

• Thread(target=..., args=(...)) — একটি thread object বানায়; কোন ফাংশন চলবে আর কী argument পাবে, তা বলে দেয়। এখনো কিছু চলেনি।
• t.start() — thread-টি সত্যিই চালু করে। এরপর main thread থেমে থাকে না, নিজের পরের লাইনে চলে যায়।
• t.join() — “এই thread শেষ না হওয়া পর্যন্ত আমি এখানে অপেক্ষা করব।” join ভুলে গেলে main thread হয়তো ফল ছাপতে চলে যাবে, অথচ কাজ তখনো শেষ হয়নি।
• ফল ছাপা হলো শেষে, ক্রম মেনে। প্রতিটি thread নিজের ফল dict-এ রেখেছে; সবাই join হওয়ার পর main thread নির্দিষ্ট ক্রমে ছেপেছে। thread-এর ভেতর থেকে সরাসরি print করলে কোন লেখা আগে আসবে, তার কোনো নিশ্চয়তা থাকে না।

Daemon thread — পেছনের সহকারী

সাধারণত Python প্রোগ্রাম শেষ হওয়ার আগে সব চালু thread শেষ হওয়ার অপেক্ষা করে। কিন্তু কিছু thread চিরকাল চলার জন্য বানানো — যেমন প্রতি মিনিটে log ফাইলে স্বাস্থ্য-তথ্য লেখা। এমন thread-কে Thread(target=..., daemon=True) দিয়ে daemon thread বানানো যায়। Main thread শেষ হলে daemon thread-গুলোকে আর অপেক্ষা না করে হঠাৎ থামিয়ে দেওয়া হয় — তাদের finally ব্লক বা ফাইল বন্ধ করার কাজ না-ও চলতে পারে। তাই ফাইলে লেখা বা ডেটাবেসে সেভ করার মতো গুরুত্বপূর্ণ কাজ কখনো daemon thread-এ রাখবেন না।

৩ · ThreadPoolExecutor — আধুনিক, সহজ পথ

প্রতিটি কাজের জন্য হাতে thread বানানো, start আর join করা ঝামেলার; ১০০০টি পাতা নামাতে ১০০০টি thread বানালে অপচয়ও। বাস্তবে প্রায় সবসময় ভালো উপায় হলো thread pool: নির্দিষ্ট কয়েকজন কর্মী আগে থেকে তৈরি থাকে, কাজগুলো একটি সারিতে জমা হয়, যে কর্মী খালি হয় সে পরের কাজ তুলে নেয়। Python 3.2 থেকে standard library-র concurrent.futures module এই কাজ সহজ করেছে (PEP 3148 অনুযায়ী)। এর executor দুই রকম — ThreadPoolExecutor আর ProcessPoolExecutor — আর দুটির ব্যবহার প্রায় একই।

নিচের ডায়াগ্রামে দেখুন, ৩ জন কর্মী কীভাবে ৬টি মুদ্রার হার আনার কাজ ভাগ করে নেয়, আর ফল কোন ক্রমে ফেরত আসে:

1codes = ["USD", "EUR", "GBP", "INR", "SAR", "JPY"]2with ThreadPoolExecutor(max_workers=3) as pool:3    for code, rate in pool.map(fetch_rate, codes):4        print(code, rate)

Executor-এর তিনটি মূল হাতিয়ার:

এবার কোডে দেখুন। এখানে আসল নেটওয়ার্কের বদলে একটি কাল্পনিক “API” (একটি dict) আর খুব ছোট time.sleep দিয়ে অপেক্ষার ভান করা হয়েছে। হারগুলোও কাল্পনিক:

import time
from concurrent.futures import ThreadPoolExecutor, as_completed

FAKE_API = {"USD": 122.5, "EUR": 133.1, "GBP": 155.8, "INR": 1.45, "SAR": 32.6}

def fetch_rate(code):
    time.sleep(0.1)                  # নেটওয়ার্কের অপেক্ষার ভান
    return code, FAKE_API[code]

codes = ["USD", "EUR", "GBP", "INR", "SAR"]
with ThreadPoolExecutor(max_workers=5) as pool:
    results = list(pool.map(fetch_rate, codes))      # ফল আসে ইনপুটের ক্রমে
    futures = [pool.submit(fetch_rate, c) for c in codes]
    rates = dict(f.result() for f in as_completed(futures))

for code, rate in results:
    print(f"1 {code} = {rate} টাকা")
print(f"as_completed: {len(rates)}টি ফল, সবচেয়ে দামি {max(rates, key=rates.get)}")

৪ · ভাগ করা ডেটা আর race condition — Lock

এতক্ষণ প্রতিটি thread নিজের আলাদা ফল রেখেছে। এবার ধরুন একটি ব্যাংকের শাখায় চারটি কাউন্টার, আর চারজন ক্যাশিয়ার একই অ্যাকাউন্টে টাকা জমা দিচ্ছেন। চারটি thread, একটি ভাগ করা ভ্যারিয়েবল balance. প্রত্যেকে লেখেন balance += 100. এক লাইনের কাজ — কী আর ভুল হতে পারে?

সমস্যা হলো, balance += 100 দেখতে এক কাজ হলেও Python-এর virtual machine-এর কাছে কয়েকটি আলাদা bytecode নির্দেশ (পর্ব ০৫ মনে করুন): মান পড়া, ১০০ যোগ, ফল লেখা। একে বলে read-modify-write. GIL একবারে একটি নির্দেশ সুরক্ষিত রাখে, পুরো লাইন নয় — দুটি নির্দেশের মাঝখানে Python অন্য thread-কে পালা দিতে পারে। তখন কী হয়, দেখুন:

1T1: পড়ো   balance2    ── Python পালা দিল T2-কে ──3T2: পড়ো   balance4T2: যোগ    + 100, লেখো5T1: যোগ    + 1006T1: লেখো   balance7# Lock থাকলে: T1-এর তিন ধাপ শেষ, তারপর T2

সমাধান: threading.Lock আর with lock:

সমাধান একটি তালা — Lock. কোডের যে অংশ ভাগ করা ডেটা পড়ে-বদলায়, তাকে বলে critical section. তার চারপাশে তালা দিন: একজন তালা ধরে থাকলে বাকিরা অপেক্ষা করে। Lock একটি context manager, তাই with lock: লিখলে ঢোকার সময় তালা লাগে, বের হওয়ার সময় — exception এলেও — নিশ্চিতভাবে খোলে। with-এর ভেতরের এই কৌশল পর্ব ৩৬-এ (context manager) দেখেছেন।

import threading

balance = 0
lock = threading.Lock()

def deposit(times):
    global balance
    for _ in range(times):
        with lock:              # একবারে একটিই thread ঢুকতে পারে
            balance += 100

workers = [threading.Thread(target=deposit, args=(10_000,)) for _ in range(4)]
for t in workers:
    t.start()
for t in workers:
    t.join()                    # সবাই শেষ না হওয়া পর্যন্ত অপেক্ষা
print("মোট জমা:", balance)
print("প্রত্যাশিত:", 4 * 10_000 * 100)

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

তালা সমস্যা মেটায়, আবার নতুন সমস্যাও আনে। ধরুন thread A আগে “হিসাবের খাতা”-র তালা নিল, তারপর “ক্যাশ বাক্স”-র তালা চাইছে। একই সময়ে thread B আগে ক্যাশ বাক্সের তালা নিয়ে এখন খাতার তালা চাইছে। দুজনেই অন্যজনের হাতের তালার জন্য অপেক্ষা করছে — চিরকাল। একে বলে deadlock: প্রোগ্রাম crash করে না, কোনো error দেখায় না, শুধু থেমে থাকে। প্রতিরোধের সবচেয়ে কার্যকর নিয়ম: একাধিক তালা লাগলে সব জায়গায় একই ক্রমে নিন; তালার ভেতরে যতটা সম্ভব কম কাজ করুন (বিশেষ করে নেটওয়ার্কের অপেক্ষা নয়); আর সম্ভব হলে তালা ভাগাভাগির বদলে পরের অংশের Queue ব্যবহার করুন। একই thread নিজে একটি সাধারণ Lock দুবার নিতে গেলেও আটকে যায় — সেই প্রয়োজনে আছে threading.RLock.

৫ · queue.Queue — তালা ছাড়াই নিরাপদ আদান-প্রদান

তালা নিয়ে কাজ করা কঠিন, কারণ প্রতিটি ভাগ করা ভ্যারিয়েবল মনে রাখতে হয়। অনেক বেশি পরিষ্কার নকশা হলো: thread-রা ডেটা ভাগ করবে না, বরং একে অপরকে বার্তা পাঠাবে. এর জন্য Python দিয়েছে queue.Queue — একটি thread-safe সারি, যার ভেতরে তালার কাজ আগে থেকেই করা আছে। একদিকে কেউ put() করে, অন্যদিকে কেউ get() করে।

import queue
import threading

orders = queue.Queue(maxsize=2)      # তাকে একসাথে সর্বোচ্চ ২টি অর্ডার
cooked = []

def chef():
    while True:
        dish = orders.get()          # খালি থাকলে অপেক্ষা
        if dish is None:             # sentinel: আজকের মতো শেষ
            break
        cooked.append(f"{dish} তৈরি")
        orders.task_done()

cook = threading.Thread(target=chef)
cook.start()
for dish in ["বিরিয়ানি", "খিচুড়ি", "চা", "কাবাব"]:
    orders.put(dish)                 # তাক ভরা থাকলে অপেক্ষা
orders.join()                        # সব অর্ডার শেষ হওয়া পর্যন্ত
orders.put(None)
cook.join()
print(cooked)

['বিরিয়ানি তৈরি', 'খিচুড়ি তৈরি', 'চা তৈরি', 'কাবাব তৈরি']

বাবুর্চি একজন, তাই অর্ডার যে ক্রমে তাকে উঠেছে সেই ক্রমেই রান্না হয়েছে — আউটপুট সবসময় একই। হাতে-কলমে ধাপগুলো দেখুন:

1বাবুর্চি: dish = orders.get()2ওয়েটার: orders.put(dish)3ওয়েটার: put — তাক ভরা, অপেক্ষা4বাবুর্চি: task_done(), আবার get()5ওয়েটার: join(), তারপর put(None)

একাধিক বাবুর্চি (consumer) রাখলে রান্না দ্রুত হবে, তবে কোন পদ কে আগে শেষ করবে তা আর নির্দিষ্ট থাকবে না — তখন প্রতিটি বাবুর্চির জন্য একটি করে None পাঠাতে হয়। Python 3.13 থেকে Queue.shutdown() নামে একটি method-ও আছে, যা sentinel ছাড়াই queue বন্ধ করার পরিষ্কার উপায় দেয়।

৬ · GIL — ভেতরের গল্প

এবার সেই বিখ্যাত তালার কথা, যার নাম আপনি পর্ব ০৫-এ প্রথম শুনেছেন। GIL (Global Interpreter Lock) হলো সাধারণ CPython-এর ভেতরের একটি তালা, যা একটি process-এ একসাথে শুধু একটি thread-কে Python bytecode চালাতে দেয়। যে thread GIL ধরে আছে, শুধু সে-ই Python object ছুঁতে পারে।

GIL কেন আছে

পর্ব ০৫-এ দেখেছেন, CPython প্রতিটি object-এর একটি reference count রাখে, আর গণনা শূন্য হলেই object মুছে দেয়। দুটি thread একই মুহূর্তে একই object-এর গণনা বাড়ালে-কমালে ঠিক উপরের balance-এর মতো lost update হতো — আর ফল টাকা হারানো নয়, ভুল সময়ে object মুছে যাওয়া, মানে interpreter crash. প্রতিটি object-এ আলাদা তালা দিলে প্রতিটি গণনা বদলে বাড়তি খরচ হতো, আর এক-thread-এর প্রোগ্রাম (যা ছিল প্রায় সব প্রোগ্রাম) ধীর হয়ে যেত।

তাই ১৯৯২ সালে Python-এ thread যোগ করার সময় Guido van Rossum বেছে নেন সরল সমাধান: পুরো interpreter-এর জন্য একটি বড় তালা। এর বড় লাভ ছিল C extension লেখকদের জন্য — তাঁদের নিজের কোডে thread-নিরাপত্তা নিয়ে প্রায় ভাবতেই হতো না, কারণ GIL ধরে থাকা অবস্থায় আর কেউ Python object ছোঁয় না। এই সরলতাই NumPy থেকে ডেটাবেস driver পর্যন্ত বিশাল C library-জগৎ গড়ে উঠতে সাহায্য করেছে।

GIL কখন হাতবদল হয়

দুটি উপায়ে একটি thread GIL ছেড়ে দেয়। এক, অপেক্ষার আগে: নেটওয়ার্ক থেকে পড়া, ফাইল পড়া, time.sleep — এমন blocking কাজের আগে CPython নিজেই GIL ছেড়ে দেয়, অপেক্ষা শেষে আবার নেয়। দুই, সময় ফুরালে: অন্য কোনো thread GIL চেয়ে অপেক্ষায় থাকলে, চলমান thread একটি নির্দিষ্ট সময় পর ছেড়ে দিতে বাধ্য হয়। এই সময়কে বলে switch interval, ডিফল্ট ৫ মিলিসেকেন্ড (sys.getswitchinterval() দিয়ে দেখা যায়)। দুই রকম thread-এর একটি দৃশ্য দেখুন:

1T1 (download): req = build_request(url)2T1 (download): data = sock.recv(4096)3T2 (হিসাব):    total += n * n   # লুপে4# দুটোই হিসাবের thread হলে?

৭ · process — CPU-ভারী কাজের আসল সমাধান

প্রতিটি process-এর নিজস্ব Python interpreter, নিজস্ব মেমরি — আর নিজস্ব GIL. তাই ৪টি process মানে ৪টি আলাদা GIL, যারা ৪টি core-এ একসাথে Python bytecode চালাতে পারে। Standard library-র multiprocessing module এই কাজ করে, আর তার আধুনিক, সহজ রূপ হলো ProcessPoolExecutor — যার ব্যবহার ThreadPoolExecutor-এর হুবহু মতো।

উদাহরণ: ১ লাখ পর্যন্ত কতগুলো prime সংখ্যা আছে, তা চারটি ভাগে চারটি process-এ গোনা। এই কোডটি নিজের কম্পিউটারে ফাইল বানিয়ে চালান:

from concurrent.futures import ProcessPoolExecutor

def count_primes(bounds):
    lo, hi = bounds
    count = 0
    for n in range(max(lo, 2), hi):
        if all(n % d for d in range(2, int(n ** 0.5) + 1)):
            count += 1
    return count

if __name__ == "__main__":
    ranges = [(0, 25_000), (25_000, 50_000), (50_000, 75_000), (75_000, 100_000)]
    with ProcessPoolExecutor(max_workers=4) as pool:
        counts = list(pool.map(count_primes, ranges))
    for (lo, hi), c in zip(ranges, counts):
        print(f"{lo}–{hi}: {c}টি prime")
    print("মোট:", sum(counts))

প্রত্যাশিত আউটপুট (যেকোনো যন্ত্রে একই):

0–25000: 2762টি prime
25000–50000: 2371টি prime
50000–75000: 2260টি prime
75000–100000: 2199টি prime
মোট: 9592

৪ core-এর মেশিনে এটি এক process-এ গোনার চেয়ে উল্লেখযোগ্যভাবে দ্রুত হয় (ঠিক ৪ গুণ নয় — কেন, তা নিচে আর ভাবনার প্রশ্নে দেখবেন)। একই কোডে শুধু ProcessPoolExecutor-কে ThreadPoolExecutor বানালে সাধারণ CPython-এ প্রায় কোনো লাভ হবে না — নিজে বদলে মেপে দেখুন। তিনটি জিনিস অবশ্যই মনে রাখতে হবে:

১. if __name__ == "__main__": বাধ্যতামূলক

নতুন process তৈরির কয়েকটি পদ্ধতি আছে। Windows আর macOS-এ ডিফল্ট পদ্ধতি spawn: একটি একদম নতুন Python interpreter চালু হয়, আর আপনার মূল ফাইলটি module হিসেবে import করে count_primes খুঁজে নেয়। পর্ব ২২-এ (module আর import) দেখেছেন, import মানে ফাইলের উপরের স্তরের সব কোড চলা। Guard না থাকলে প্রতিটি নতুন process আবার pool বানাতে চাইত, সে আবার নতুন process — তাই Python এটা আটকে দিয়ে RuntimeError দেখায়। main guard-এর ভেতরের কোড শুধু আসল মূল process-এ চলে, import-এর সময় নয়। Linux-এ আগে ডিফল্ট ছিল fork (চলমান process-এর হুবহু কপি), যেখানে guard ছাড়াও কোড চলত — তাই Linux-এ লেখা কোড Windows-এ গিয়ে ভাঙত। Python 3.14 থেকে Linux-এও ডিফল্ট বদলে forkserver হয়েছে, যেখানে guard আবার জরুরি। সহজ নিয়ম: process ব্যবহার করলে সবসময় main guard.

২. Argument আর ফল pickle হয়ে যাতায়াত করে

Process-রা মেমরি ভাগ করে না। তাই count_primes-এ যে tuple পাঠালেন, তা pickle করে (byte-এ বদলে) অন্য process-এ পাঠানো হয়, সেখানে আবার object বানানো হয়; ফলও একইভাবে ফেরত আসে। এর তিনটি ফল আছে: lambda বা অন্য ফাংশনের ভেতরে লেখা ফাংশন সাধারণত পাঠানো যায় না (pickle হয় না) — ফাংশন হতে হবে module-এর উপরের স্তরে; বড় ডেটা (ধরুন ২ GB-র list) পাঠালে কপির খরচ বিশাল; আর worker process-এ কোনো global ভ্যারিয়েবল বদলালে মূল process তা দেখে না।

৩. Process দামি

একটি thread তৈরি হয় মাইক্রোসেকেন্ডে; একটি process (বিশেষ করে spawn-এ) চালু হতে interpreter লোড করতে হয়, যাতে অনেক বেশি সময় আর মেমরি লাগে। তাই process তখনই লাভজনক, যখন প্রতিটি কাজ যথেষ্ট বড় — হাজারটা ছোট কাজের জন্য হাজারটা পাঠানোর বদলে কয়েকটি বড় খণ্ডে ভাগ করুন (উপরে যেমন ৪টি পরিসর), অথবা pool.map(fn, items, chunksize=100) ব্যবহার করুন।

৮ · Free-threaded Python — GIL ছাড়া CPython

বহু বছর ধরে “Python-এ সত্যিকারের parallel thread নেই” কথাটি প্রায় প্রবাদ ছিল। এখন তা বদলাচ্ছে, তবে ধাপে ধাপে, সাবধানে। সঠিক তথ্যগুলো একটু মনোযোগ দিয়ে পড়ুন, কারণ ইন্টারনেটে (আর AI-এর উত্তরে) এ নিয়ে অনেক ভুল আছে।

Free-threaded build সাধারণত আলাদা নামের একটি executable — যেমন python3.14t (শেষের t দিয়ে threaded বোঝানো হয়)। python.org-এর Windows ও macOS installer-এ এটি একটি ঐচ্ছিক অংশ হিসেবে বেছে নেওয়া যায়, আর uv-এর মতো টুল দিয়েও ইনস্টল করা যায়। আপনি কোনটি চালাচ্ছেন, তা যাচাই করতে পারেন:

$ python3.14t -VV
Python 3.14.0 free-threading build (...)
$ python3.14t -c "import sys; print(sys._is_gil_enabled())"
False

এই build-এ উপরের prime-গোনার কোডে শুধু ThreadPoolExecutor ব্যবহার করলেই চারটি thread চারটি core-এ সত্যিই একসাথে চলতে পারে — process-এর pickle বা চালুর খরচ ছাড়া। কিন্তু কয়েকটি কথা জেনে রাখুন:

• C extension-কে সমর্থন জানাতে হয়। GIL না থাকলে C extension-গুলোকে নিজের thread-নিরাপত্তা নিজেকেই নিশ্চিত করতে হয়, আর সেই অনুযায়ী আলাদা করে build করতে হয়। যে extension নিজেকে free-threading-এর উপযুক্ত বলে ঘোষণা করেনি, তা import করলে interpreter নিরাপত্তার জন্য সাধারণত GIL আবার চালু করে দেয় এবং একটি সতর্কবার্তা দেখায়। NumPy-সহ জনপ্রিয় অনেক library ইতোমধ্যে সমর্থন যোগ করেছে, কিন্তু সব নয় — আপনার প্রয়োজনীয় library-গুলো আগে যাচাই করুন।
• এক-thread-এর কোডে সামান্য খরচ। Thread-নিরাপদ reference counting আর মেমরি ব্যবস্থার কারণে free-threaded build-এ এক-thread-এর কোড কিছুটা ধীর। 3.13-এ এই খরচ বেশ চোখে পড়ার মতো ছিল; 3.14-এ তা অনেক কমেছে (Python-এর ডকুমেন্টেশন অনুযায়ী মোটামুটি ৫–১০%), তবে কাজভেদে আলাদা।
• Race condition আরও সহজে দেখা দেয়। Thread সত্যিই একসাথে চললে balance += 100-এর lost update নিয়মিত ঘটবে। অর্থাৎ GIL উঠে গেলে Lock আর Queue-র গুরুত্ব আরও বাড়ে, কমে না। Built-in list বা dict-এর ভেতরের গঠন অবশ্য এই build-এও ভাঙে না — CPython সেগুলো নিজেই সুরক্ষিত রাখে; আপনার নিজের যুক্তির race আপনাকেই সামলাতে হবে।

আরও একটি নতুন পথ আছে, শুধু নাম জেনে রাখুন: Python 3.14-এ এসেছে concurrent.interpreters module আর InterpreterPoolExecutor — একই process-এর ভেতরে একাধিক আলাদা interpreter, প্রত্যেকের নিজস্ব GIL. এটি thread আর process-এর মাঝামাঝি একটি পথ, এখনো নতুন।

৯ · কোনটা কখন — বেছে নেওয়ার নিয়ম আর আগে মাপা

এত হাতিয়ার দেখে বিভ্রান্ত হওয়া স্বাভাবিক। নিচের টেবিলটি বেশিরভাগ সিদ্ধান্তের জন্য যথেষ্ট:

সমান্তরাল করার আগে মাপুন

অভিজ্ঞ প্রোগ্রামারের প্রথম প্রশ্ন “কীভাবে সমান্তরাল করব?” নয়, বরং “সময় আসলে কোথায় যাচ্ছে?” হয়তো দেখবেন ৯০% সময় যাচ্ছে একটি ভুল নকশার লুপে, যা একটি dict ব্যবহার করলেই ১০০ গুণ দ্রুত হয় — কোনো thread ছাড়াই। কীভাবে cProfile আর timeit দিয়ে মাপতে হয়, তা পর্ব ৪৩-এ (পারফরম্যান্স — মেপে দ্রুত করা) শিখবেন।

আর মনে রাখুন Amdahl's law: প্রোগ্রামের যে অংশ সমান্তরাল করা যায় না, সেটিই শেষ পর্যন্ত গতির সীমা ঠিক করে। ধরুন প্রোগ্রামের ৮০% ভাগ করা যায়, ২০% যায় না। অসীম core দিলেও ওই ২০% সময় থাকবেই — তাই সর্বোচ্চ লাভ ৫ গুণ। ৪টি core-এ লাভ মাত্র ২.৫ গুণ। Process চালু করা আর ডেটা পাঠানোর খরচ যোগ করলে আরও কম।

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

“আমার স্ক্রিপ্টটা দ্রুত করে দাও” বললে AI প্রায়ই সঙ্গে সঙ্গে thread বা process যোগ করে দেয়। কোড দেখতে পেশাদার লাগে, চলেও। কিন্তু concurrency-র bug সবচেয়ে লুকানো bug — বেশিরভাগ সময় ঠিক চলে, মাঝে মাঝে ভুল করে। আর এ বিষয়ে AI-এর প্রশিক্ষণ-ডেটার বড় অংশ free-threading আসার আগের। সাধারণ ভুলগুলো চিনে রাখুন:

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

• কাজটি I/O-bound না CPU-bound, তা নিজে নিশ্চিত হয়েছি — আর বেছে নেওয়া পদ্ধতি তার সাথে মেলে
• একাধিক thread যে ভ্যারিয়েবল বদলায়, তার প্রতিটি তালা বা Queue দিয়ে সুরক্ষিত
• প্রতিটি thread join হয়েছে, বা executor-এর with ব্লক ব্যবহার হয়েছে
• Process-কোডে main guard আছে, আর পাঠানো ফাংশন module-এর উপরের স্তরে
• আগে-পরে সময় মেপে দেখেছি সত্যিই দ্রুত হলো কি না — শুধু AI-এর কথায় বিশ্বাস করিনি