ما هي race conditions، وكيف تمنعها الـ mutexes والـ semaphores؟

Question

IT Interview Practice · Accepted Answer

حين تتشارك خيوط متعددة بيانات، يمكن أن **تتشابك (interleave)** عملياتها في منتصف تحديث متعدد الخطوات، مُنتِجةً **race condition** — خللًا تعتمد فيه النتيجة على توقيت لا يمكن التنبّؤ به. والـ **تزامن (synchronization)** هو مجموعة الأدوات التي تفرض ترتيبًا آمنًا.

## المشكلة: 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 (قفل)** — إقصاء متبادل: خيط واحد فقط يحمله في كل لحظة؛ ويُحجَب الآخرون حتى يُحرَّر. غلِّف الـ critical section:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — حصري، لا يدخله سوى خيط واحد
pthread_mutex_unlock(&m);
```

- **Semaphore** — عدّاد يسمح بحُمّال متزامنين حتى *N*. الـ semaphore الثنائي (N=1) يعمل كقفل؛ والـ semaphore العدّاد يحدّ، مثلًا، connection pool عند N مستخدمين. يُستخدَم أيضًا للـ **إشارة (signaling)** بين الخيوط (producer/consumer).
- **Condition variable** — يدع خيطًا ينام حتى تصير مقولة صحيحة (مثل "الطابور غير فارغ")، فيستيقظ دون busy-waiting.
- **العمليات الذرّية (Atomic operations)** — تعليمات عتادية مثل compare-and-swap (CAS) تنفّذ قراءة-تعديل-كتابة بلا تجزئة، مُتيحةً عدّادات lock-free.

## المزالق

تحلّ الأقفال الـ races لكنها تُدخِل مخاطر جديدة: **deadlock** (خيوط تنتظر أقفال بعضها)، و**priority inversion** (قلب الأولوية)، و**contention** (تنازع — تسلسل الخيوط، ما يقتل التوازي). القاعدة العملية: أبقِ الـ critical sections **قصيرة**، واكتسب دائمًا أقفالًا متعددة بـ **ترتيب عالمي متّسق**.

## لماذا يهم

من أصعب العلل اكتشافًا علل التزامن (concurrency) — فهي غير حتمية وكثيرًا ما تختفي تحت المنقّح (debugger). يريد المُقابِلون أن يروا أنك تستطيع *رصد* critical section، واختيار البدائية الصحيحة (mutex مقابل semaphore مقابل atomic)، والتعليل حول أنماط الفشل (deadlock، contention). ينطبق هذا مباشرةً على أي خادم متعدد الخيوط، أو cache مشتركة، أو عدّاد.

المشكلة: race condition

الأدوات

المزالق

لماذا يهم

أسئلة ذات صلة