Race conditions म्हणजे काय, आणि mutexes व semaphores ती कशी टाळतात?

Question

IT Interview Practice · Accepted Answer

जेव्हा अनेक threads data सामायिक करतात, तेव्हा त्यांच्या क्रिया एका बहु-टप्प्याच्या update च्या मध्येच interleave होऊ शकतात, ज्यामुळे race condition निर्माण होते — असा bug जिथे परिणाम अनिश्चित 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** — असा code जो सामायिक state ला स्पर्श करतो आणि एकाच वेळी चालू नये.

## साधने

- **Mutex (lock)** — mutual exclusion: एका वेळी फक्त एक thread ते धारण करतो; इतर thread ते सोडेपर्यंत block होतात. Critical section ला गुंडाळा:

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

- **Semaphore** — *N* पर्यंत एकाच वेळी धारकांना परवानगी देणारा counter. Binary semaphore (N=1) lock सारखा वागतो; counting semaphore, उदाहरणार्थ, connection pool ला N वापरकर्त्यांवर मर्यादित करतो. threads दरम्यान **signaling** साठीदेखील वापरला जातो (producer/consumer).
- **Condition variable** — एखादा predicate खरा होईपर्यंत (उदा. "queue रिकामी नाही") thread ला झोपू देतो, busy-waiting शिवाय जागा होतो.
- **Atomic operations** — compare-and-swap (CAS) सारख्या हार्डवेअर instructions जे read-modify-write अविभाज्यपणे करतात, ज्यामुळे lock-free counters शक्य होतात.

## धोके

Locks races सोडवतात पण नवे धोके आणतात: **deadlock** (threads एकमेकांच्या locks ची वाट पाहतात), **priority inversion**, आणि **contention** (threads serialize होतात, parallelism मारतात). अंगठ्याचा नियम: critical sections **लहान** ठेवा, आणि नेहमी अनेक locks एका **सुसंगत global क्रमाने** मिळवा.

## हे का महत्त्वाचे आहे

Concurrency bugs हे शोधायला सर्वात कठीण असतात — ते nondeterministic असतात आणि अनेकदा debugger खाली गायब होतात. Interviewers ना हे पाहायचे असते की तुम्ही critical section *ओळखू* शकता का, योग्य primitive (mutex vs semaphore vs atomic) निवडू शकता का, आणि failure modes (deadlock, contention) चा तर्क लावू शकता का. हे कोणत्याही multithreaded server, shared cache, किंवा counter ला थेट लागू होते.

समस्या: एक race condition

साधने

धोके

हे का महत्त्वाचे आहे

संबंधित प्रश्न