race conditions کیا ہیں، اور mutexes اور semaphores انہیں کیسے روکتے ہیں؟

Question

IT Interview Practice · Accepted Answer

جب متعدد threads ڈیٹا شیئر کرتے ہیں، تو ان کے آپریشنز کسی کثیر مرحلہ اپڈیٹ کے بیچ میں گڈمڈ (interleave) ہو سکتے ہیں، جس سے ایک race condition پیدا ہوتی ہے — ایک ایسا bug جہاں نتیجہ ناقابلِ پیش گوئی timing پر منحصر ہوتا ہے۔ Synchronization ان اوزاروں کا مجموعہ ہے جو محفوظ ترتیب پر مجبور کرتے ہیں۔

مسئلہ: ایک race condition

جوہری (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         ┘
```

پڑھنے اور لکھنے کے درمیان کی کھڑکی ایک **critical section** ہے — وہ کوڈ جو شیئرڈ حالت کو چھوتا ہے اور بیک وقت نہیں چلنا چاہیے۔

## اوزار

- **Mutex (lock)** — باہمی اخراج (mutual exclusion): ایک وقت میں صرف ایک thread اسے تھامتا ہے؛ باقی اس کے چھوڑے جانے تک بلاک رہتے ہیں۔ critical section کو لپیٹ لیں:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — exclusive
pthread_mutex_unlock(&m);
```

- **Semaphore** — ایک counter جو زیادہ سے زیادہ *N* بیک وقت holders کی اجازت دیتا ہے۔ ایک binary semaphore (N=1) ایک lock کی طرح کام کرتا ہے؛ ایک counting semaphore، مثلاً ایک connection pool کو N صارفین پر محدود کرتا ہے۔ threads کے درمیان **signaling** (producer/consumer) کے لیے بھی استعمال ہوتا ہے۔
- **Condition variable** — کسی thread کو تب تک سونے دیتا ہے جب تک ایک predicate سچ نہ ہو جائے (مثلاً "queue خالی نہیں")، بغیر busy-waiting کے جاگتے ہوئے۔
- **Atomic operations** — ہارڈویئر instructions جیسے compare-and-swap (CAS) جو read-modify-write کو ناقابلِ تقسیم انداز میں کرتے ہیں، lock-free counters کو ممکن بناتے ہوئے۔

## پھندے (pitfalls)

Locks races حل کرتے ہیں لیکن نئے خطرات لاتے ہیں: **deadlock** (threads ایک دوسرے کے locks کا انتظار کرتے ہوئے)، **priority inversion**، اور **contention** (threads قطار میں لگ جاتے ہیں، متوازی کاری کو مار دیتے ہوئے)۔ عمومی اصول: critical sections کو **مختصر** رکھیں، اور ہمیشہ متعدد locks کو ایک **مستقل عالمی ترتیب** میں حاصل کریں۔

## یہ کیوں اہم ہے

Concurrency bugs ڈھونڈنے میں سب سے مشکل میں سے ہیں — یہ غیر متعین (nondeterministic) ہوتے ہیں اور اکثر debugger کے نیچے غائب ہو جاتے ہیں۔ انٹرویو لینے والے دیکھنا چاہتے ہیں کہ آپ کسی critical section کو *پہچان* سکتے ہیں، درست primitive چن سکتے ہیں (mutex بمقابلہ semaphore بمقابلہ atomic)، اور خرابی کے طریقوں (deadlock، contention) کے بارے میں استدلال کر سکتے ہیں۔ یہ کسی بھی multithreaded server، شیئرڈ cache، یا counter پر براہِ راست لاگو ہوتا ہے۔

مسئلہ: ایک race condition

اوزار

پھندے (pitfalls)

یہ کیوں اہم ہے

متعلقہ سوالات