Race conditions શું છે, અને mutexes તથા semaphores તેમને કેવી રીતે અટકાવે છે?

Question

IT Interview Practice · Accepted Answer

જ્યારે અનેક threads data વહેંચે છે, ત્યારે તેમની operations એક multi-step 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         ┘
```

વાંચન અને લેખન વચ્ચેની બારી એ **critical section** છે — એવો code જે shared state ને સ્પર્શે છે અને એકસાથે (concurrently) ચાલવો ન જોઈએ.

## સાધનો

- **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 holders ને પરવાનગી આપે છે. Binary semaphore (N=1) lock જેવું વર્તે છે; counting semaphore, દા.ત., connection pool ને N users પર મર્યાદિત કરે છે. threads વચ્ચે **signaling** (producer/consumer) માટે પણ વપરાય છે.
- **Condition variable** — thread ને એક predicate સાચું થાય ત્યાં સુધી (દા.ત. "queue ખાલી નથી") સૂવા દે છે, busy-waiting વગર જાગે છે.
- **Atomic operations** — compare-and-swap (CAS) જેવી hardware instructions જે read-modify-write અવિભાજ્ય રીતે કરે છે, lock-free counters ને શક્ય બનાવે છે.

## મુશ્કેલીઓ

Locks races ઉકેલે છે પણ નવા જોખમો લાવે છે: **deadlock** (threads એકબીજાના locks પર રાહ જુએ છે), **priority inversion**, અને **contention** (threads serialize થાય છે, parallelism ને મારી નાખે છે). અંગૂઠાનો નિયમ: critical sections ને **ટૂંકા** રાખો, અને હંમેશા બહુવિધ locks ને **સુસંગત global order** માં મેળવો.

## આ શા માટે મહત્વનું છે

Concurrency bugs શોધવા સૌથી અઘરા પૈકી છે — તે nondeterministic છે અને ઘણી વાર debugger હેઠળ ગાયબ થઈ જાય છે. Interviewers જોવા માગે છે કે તમે critical section ને *ઓળખી* શકો, યોગ્ય primitive (mutex vs semaphore vs atomic) પસંદ કરી શકો, અને failure modes (deadlock, contention) વિશે તર્ક કરી શકો. આ કોઈપણ multithreaded server, shared cache, કે counter પર સીધું લાગુ પડે છે.

સમસ્યા: એક race condition

સાધનો

મુશ્કેલીઓ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો