Race conditionలు అంటే ఏమిటి, mutexలు మరియు semaphoreలు వాటిని ఎలా నివారిస్తాయి?

Question

IT Interview Practice · Accepted Answer

అనేక threadలు డేటాను పంచుకున్నప్పుడు, వాటి ఆపరేషన్‌లు బహుళ-దశల నవీకరణ మధ్యలో interleave కావచ్చు, ఒక race conditionను — ఫలితం ఊహించలేని timing మీద ఆధారపడే బగ్ — సృష్టిస్తుంది. Synchronization అనేది సురక్షితమైన క్రమాన్ని బలవంతం చేసే పరికరాల సమూహం.

సమస్య: ఒక 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         ┘
```

చదవడం మరియు వ్రాయడం మధ్య ఉన్న విండో ఒక **critical section** — పంచుకున్న stateను తాకే, ఏకకాలంలో నడవకూడని కోడ్.

## పరికరాలు

- **Mutex (lock)** — mutual exclusion: ఒక సమయంలో ఒకే thread దాన్ని పట్టుకుంటుంది; ఇతరులు అది విడుదలయ్యే వరకు block అవుతారు. critical sectionను చుట్టండి:

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

- **Semaphore** — గరిష్ఠంగా *N* ఏకకాల holdersను అనుమతించే counter. ఒక binary semaphore (N=1) lockలా పనిచేస్తుంది; ఒక counting semaphore, ఉదాహరణకు, ఒక connection poolను N vinియోగదారులకు పరిమితం చేస్తుంది. threadల మధ్య **signaling**కు కూడా వాడతారు (producer/consumer).
- **Condition variable** — ఒక predicate నిజమయ్యే వరకు (ఉదా. "queue not empty") ఒక threadను నిద్రపోనిస్తుంది, busy-wait లేకుండా మేల్కొంటుంది.
- **Atomic operations** — compare-and-swap (CAS) వంటి హార్డ్‌వేర్ instructions, ఇవి read-modify-writeను విభజించలేని విధంగా చేస్తాయి, lock-free countersను సాధ్యం చేస్తాయి.

## గోతులు

Lockలు raceలను పరిష్కరిస్తాయి కానీ కొత్త ప్రమాదాలను తెస్తాయి: **deadlock** (threadలు ఒకదాని lockల కోసం మరొకటి వేచిచూడటం), **priority inversion**, మరియు **contention** (threadలు serialize అవుతాయి, parallelismను చంపుతాయి). నియమం: critical sectionలను **చిన్నగా** ఉంచండి, మరియు అనేక lockలను ఎల్లప్పుడూ **స్థిరమైన global orderలో** పొందండి.

## ఇది ఎందుకు ముఖ్యం

Concurrency బగ్‌లు కనుగొనడానికి అత్యంత కష్టమైనవి — అవి nondeterministic, తరచుగా debugger కింద మాయమవుతాయి. ఇంటర్వ్యూయర్‌లు మీరు ఒక critical sectionను *గుర్తించగలరో*, సరైన primitiveను (mutex vs semaphore vs atomic) ఎంచుకోగలరో, వైఫల్య మోడ్‌ల (deadlock, contention) గురించి తర్కించగలరో చూడాలనుకుంటారు. ఇది ఏ multithreaded server, shared cache, లేదా counterకైనా నేరుగా వర్తిస్తుంది.

సమస్య: ఒక race condition

పరికరాలు

గోతులు

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు