ক্রিটিক্যাল সেকশন প্রবলেম

১ · রেস কন্ডিশন কী

L08-এ আমরা দেখেছিলাম শেয়ার্ড মেমরি IPCShared Memory IPCএকাধিক প্রসেস একটি সাধারণ মেমরি অঞ্চল সরাসরি পড়তে/লিখতে পারে — দ্রুত, কিন্তু কোঅর্ডিনেশনের দায়িত্ব প্রসেসগুলোর নিজেদের। — যেখানে একাধিক প্রসেস সরাসরি একটি শেয়ার্ড মেমরি অঞ্চল অ্যাক্সেস করে। কিন্তু এই সুবিধারই একটি বিপজ্জনক দিক আছে — যদি দুই বা ততোধিক প্রসেস/থ্রেড কোনো কোঅর্ডিনেশন ছাড়াই একই শেয়ার্ড ডেটা একসাথে পড়ে/লেখে, তাহলে চূড়ান্ত ফলাফল নির্ভর করে ফেলে তাদের এক্সিকিউশনের অনির্দেশ্য টাইমিং বা ইন্টারলিভিং-এর ওপর — একে বলা হয় রেস কন্ডিশনRace Conditionএকাধিক প্রসেস/থ্রেড শেয়ার্ড ডেটা একসাথে অ্যাক্সেস করলে এবং চূড়ান্ত ফলাফল তাদের এক্সিকিউশনের timing/ordering-এর ওপর নির্ভর করলে যে পরিস্থিতি তৈরি হয়।। এটি কোনো তাত্ত্বিক সমস্যা নয় — প্রতিদিন লেখা কনকারেন্ট কোডে এটি সবচেয়ে সাধারণ ও বিপজ্জনক বাগগুলোর একটি, কারণ এটি সবসময় ঘটে না (টাইমিং-নির্ভর), তাই টেস্টিংয়েও প্রায়ই ধরা পড়ে না।

২ · ক্রিটিক্যাল সেকশন — সংজ্ঞা ও কাঠামো

প্রতিটি প্রসেসের কোডে সেই নির্দিষ্ট অংশটুকু, যেখানে সে শেয়ার্ড ডেটা অ্যাক্সেস (পড়ে বা পরিবর্তন) করে, তাকে বলা হয় ক্রিটিক্যাল সেকশনCritical Sectionপ্রসেসের কোডের সেই অংশ যেখানে শেয়ার্ড ডেটা অ্যাক্সেস হয় — একসাথে মাত্র একটি প্রসেস এখানে থাকতে পারবে।। এই সমস্যা সমাধান করতে হলে প্রতিটি প্রসেসের কোডকে চারটি অংশে ভাগ করে ভাবা হয়:

entry section — ক্রিটিক্যাল সেকশনে ঢোকার অনুমতি চাওয়ার কোড (এখানেই lock/semaphore-এর মতো টুল বসে, L18 দেখুন)। critical section — শেয়ার্ড ডেটা অ্যাক্সেসের প্রকৃত কোড। exit section — বেরিয়ে যাওয়ার ঘোষণা (lock release)। remainder section — বাকি সব সাধারণ কোড, যা শেয়ার্ড ডেটা স্পর্শ করে না।

৩ · তিনটি প্রয়োজনীয় শর্ত

একটি সঠিক ক্রিটিক্যাল-সেকশন সমাধানকে অবশ্যই এই তিনটি শর্ত একসাথে পূরণ করতে হবে —

৪ · কোডে রেস কন্ডিশন — একটি "হারানো" increment

একটি সাধারণ shared_counter += 1 দেখতে একক ধাপের মনে হলেও, প্রসেসরের স্তরে এটি আসলে তিনটি আলাদা সাব-স্টেপ: (১) বর্তমান মান read করা, (২) স্থানীয়ভাবে ১ add করা, (৩) নতুন মান আবার শেয়ার্ড ভেরিয়েবলে write করা। যদি দুটি প্রসেস এই সাব-স্টেপগুলো একে অপরের সাথে ইন্টারলিভড হয়ে চালায় (কোনো ক্রিটিক্যাল-সেকশন সুরক্ষা ছাড়া), তাহলে একটি increment হারিয়ে যেতে পারে। নিচের কোডে আমরা এই ইন্টারলিভিং সরাসরি লিখেই দেখাচ্ছি (deliberately) — যাতে বাগটি প্রতিবার একইভাবে প্রজনন হয়, বাস্তব থ্রেডিং-এর র‍্যান্ডম টাইমিং-এর ওপর নির্ভর না করে।

# একটি "shared_counter" -- P1 ও P2 দুজনেই এটি ২ বার করে বাড়াতে চায় (মোট প্রত্যাশিত বৃদ্ধি = 4)
# কিন্তু increment আসলে ৩টি সাব-স্টেপ -- read, add, write -- আমরা সেগুলো আলাদা ফাংশন হিসেবে লিখছি
shared_counter = 0
local = {"P1": None, "P2": None}  # প্রতিটি প্রসেসের নিজস্ব "রেজিস্টার" (read করা মান)

def read_step(name):
    global shared_counter
    local[name] = shared_counter
    print(f"{name}: read()  -> shared_counter={shared_counter}, local[{name}]={local[name]}")

def add_step(name):
    local[name] += 1
    print(f"{name}: add(1)  -> local[{name}]={local[name]}")

def write_step(name):
    global shared_counter
    shared_counter = local[name]
    print(f"{name}: write() -> shared_counter={shared_counter}")

# ডেলিবারেটলি ইন্টারলিভড শিডিউল -- প্রথম রাউন্ডে P1 ও P2 একসাথে রেস করে (কোনো ক্রিটিক্যাল-সেকশন সুরক্ষা নেই)
schedule = [
    ("P1", read_step), ("P2", read_step),    # দুজনেই একই stale মান পড়ে ফেলল
    ("P1", add_step),  ("P2", add_step),
    ("P1", write_step),("P2", write_step),   # P2-এর write, P1-এর write-কে ওভাররাইট করলো -- ১টি increment হারালো
    # দ্বিতীয় রাউন্ড -- এবার কোনো ওভারল্যাপ নেই (পুরোপুরি সিকোয়েন্সিয়াল), তাই এই দুটো সঠিকভাবেই গণনা হবে
    ("P1", read_step), ("P1", add_step), ("P1", write_step),
    ("P2", read_step), ("P2", add_step), ("P2", write_step),
]

for name, step in schedule:
    step(name)

expected = 4  # P1 ২ বার + P2 ২ বার ইনক্রিমেন্ট করার চেষ্টা করেছে
print()
print("ফাইনাল shared_counter =", shared_counter)
print("প্রত্যাশিত (রেস না হলে) =", expected)
print("লস্ট আপডেট হয়েছে!" if shared_counter < expected else "কোনো লস্ট আপডেট হয়নি।")