Race condition কী, এবং mutex ও semaphore কীভাবে সেগুলো ঠেকায়?

Question

IT Interview Practice · Accepted Answer

যখন একাধিক thread data ভাগ করে, তাদের operation একটি বহু-ধাপ update-এর মাঝখানে interleave হতে পারে, যা একটি race condition তৈরি করে — একটি bug যেখানে ফলাফল অননুমেয় timing-এর ওপর নির্ভর করে। Synchronization হলো সেই সরঞ্জামগুলোর সেট যা নিরাপদ ordering জোর করে চাপায়।

সমস্যা: একটি race condition

count++ দেখতে atomic মনে হয় কিন্তু আসলে এটি read-modify-write:

## সমস্যা: একটি race condition

`count++` দেখতে atomic মনে হয় কিন্তু আসলে এটি read-modify-write:

```c
// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐           interleaving loses an update:
// thread B: read count (0) ─┤  both read 0, both write 1 → count == 1, not 2
// thread A: write 1         │
// thread B: write 1         ┘
```

Read আর write-এর মধ্যেকার জানালাটি একটি **critical section** — সেই code যা shared state ছোঁয় এবং একই সাথে চলা উচিত নয়।

## সরঞ্জামগুলো

- **Mutex (lock)** — mutual exclusion: একবারে শুধু একটি thread এটি ধরে রাখে; বাকিরা মুক্ত না হওয়া পর্যন্ত block হয়ে থাকে। Critical section-টি মুড়ে দিন:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — একচেটিয়া (exclusive)
pthread_mutex_unlock(&m);
```

- **Semaphore** — একটি counter যা সর্বোচ্চ *N* সংখ্যক concurrent holder-কে অনুমতি দেয়। একটি binary semaphore (N=1) একটি lock-এর মতো কাজ করে; একটি counting semaphore, ধরুন, একটি connection pool-কে N user-এ সীমাবদ্ধ করে। এটি thread-দের মধ্যে **signaling**-এর জন্যও ব্যবহৃত হয় (producer/consumer)।
- **Condition variable** — একটি thread-কে ঘুমাতে দেয় যতক্ষণ না একটি predicate সত্য হয় (যেমন "queue খালি নয়"), busy-wait ছাড়াই জেগে ওঠে।
- **Atomic operation** — compare-and-swap (CAS)-এর মতো hardware instruction যা read-modify-write অবিভাজ্যভাবে করে, lock-free counter সম্ভব করে।

## ফাঁদগুলো

Lock race সমাধান করে কিন্তু নতুন ঝুঁকি আনে: **deadlock** (thread-রা একে অপরের lock-এর জন্য অপেক্ষা করছে), **priority inversion**, আর **contention** (thread-রা serialize হয়ে যায়, parallelism মেরে ফেলে)। থাম্ব রুল: critical section **ছোট** রাখুন, এবং সবসময় একাধিক lock একটি **সামঞ্জস্যপূর্ণ global order**-এ নিন।

## এটি কেন গুরুত্বপূর্ণ

Concurrency bug খুঁজে পাওয়া সবচেয়ে কঠিনগুলোর একটি — এগুলো nondeterministic এবং প্রায়ই debugger-এর নিচে উবে যায়। Interviewer-রা দেখতে চান আপনি একটি critical section *শনাক্ত* করতে পারেন, সঠিক primitive বেছে নিতে পারেন (mutex বনাম semaphore বনাম atomic), এবং failure mode (deadlock, contention) নিয়ে যুক্তি সাজাতে পারেন। এটি যেকোনো multithreaded server, shared cache, বা counter-এ সরাসরি প্রযোজ্য।

সমস্যা: একটি race condition

সরঞ্জামগুলো

ফাঁদগুলো

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন