Race conditions என்றால் என்ன, மேலும் mutexes மற்றும் semaphores அவற்றை எப்படித் தடுக்கின்றன?

Question

IT Interview Practice · Accepted Answer

பல threads data-ஐப் பகிரும்போது, அவற்றின் செயல்பாடுகள் ஒரு பல-படி update-இன் நடுவில் interleave ஆகலாம், இது ஒரு race condition-ஐ உருவாக்குகிறது — முடிவு கணிக்க முடியாத timing-ஐச் சார்ந்திருக்கும் ஒரு bug. 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         ┘
```

Read-க்கும் write-க்கும் இடையிலான window ஒரு **critical section** — பகிரப்பட்ட நிலையைத் தொடும், ஒரே நேரத்தில் இயங்கக்கூடாத code.

## கருவிகள்

- **Mutex (lock)** — mutual exclusion: ஒரு நேரத்தில் ஒரு thread மட்டுமே அதை வைத்திருக்கிறது; அது release ஆகும்வரை மற்றவை block ஆகின்றன. Critical section-ஐ wrap செய்யவும்:

```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 பயனர்களில் தடுக்கிறது. Threads-க்கு இடையே **signaling**-க்கும் (producer/consumer) பயன்படுகிறது.
- **Condition variable** — ஒரு predicate உண்மையாகும்வரை (உ.ம். "queue காலியாக இல்லை") ஒரு thread-ஐ உறங்க அனுமதிக்கிறது, 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-இன் கீழ் மறைந்துவிடுகின்றன. நீங்கள் ஒரு critical section-ஐ *கண்டறிய*, சரியான primitive-ஐ (mutex vs semaphore vs atomic) தேர்ந்தெடுக்க, மற்றும் failure modes (deadlock, contention) பற்றி சிந்திக்க முடியும் என்பதை interviewers பார்க்க விரும்புகிறார்கள். இது எந்த multithreaded server, பகிரப்பட்ட cache, அல்லது counter-க்கும் நேரடியாகப் பொருந்துகிறது.

சிக்கல்: ஒரு race condition

கருவிகள்

ஆபத்துகள்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்