race conditions ਕੀ ਹਨ, ਅਤੇ mutexes ਤੇ semaphores ਇਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

ਜਦੋਂ ਕਈ threads ਡਾਟਾ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਇੱਕ ਬਹੁ-ਪੜਾਵੀ ਅੱਪਡੇਟ ਦੇ ਵਿਚਕਾਰ ਆਪਸ ਵਿੱਚ ਗੁੰਦ (interleave) ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਇੱਕ race condition ਪੈਦਾ ਹੁੰਦਾ ਹੈ — ਇੱਕ bug ਜਿੱਥੇ ਨਤੀਜਾ ਅਣ-ਅਨੁਮਾਨਯੋਗ timing ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। Synchronization ਉਹ ਟੂਲਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਸੁਰੱਖਿਅਤ ਕ੍ਰਮ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ।

ਸਮੱਸਿਆ: ਇੱਕ race condition

atomic ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ read-modify-write ਹੈ:

## ਸਮੱਸਿਆ: ਇੱਕ race condition

`count++` atomic ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ read-modify-write ਹੈ:

```c
// ਦੋ threads, ਸਾਂਝਾ int count = 0, ਹਰ ਇੱਕ count++ ਇੱਕ ਵਾਰ ਕਰਦਾ ਹੈ
// thread A: read count (0) ─┐           interleaving ਇੱਕ update ਗੁਆ ਦਿੰਦੀ ਹੈ:
// thread B: read count (0) ─┤  ਦੋਵੇਂ 0 ਪੜ੍ਹਦੇ, ਦੋਵੇਂ 1 ਲਿਖਦੇ → count == 1, ਨਾ ਕਿ 2
// thread A: write 1         │
// thread B: write 1         ┘
```

ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਵਿਚਕਾਰਲੀ ਖਿੜਕੀ ਇੱਕ **critical section** ਹੈ — ਉਹ code ਜੋ ਸਾਂਝੀ ਸਥਿਤੀ ਨੂੰ ਛੂੰਹਦਾ ਹੈ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਨਹੀਂ ਚੱਲਣਾ ਚਾਹੀਦਾ।

## ਟੂਲ

- **Mutex (lock)** — ਆਪਸੀ ਬੇਦਖ਼ਲੀ (mutual exclusion): ਇੱਕ ਸਮੇਂ ਸਿਰਫ਼ ਇੱਕ thread ਇਸਨੂੰ ਫੜਦਾ ਹੈ; ਬਾਕੀ ਉਦੋਂ ਤੱਕ block ਰਹਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਇਹ ਛੱਡਿਆ ਨਹੀਂ ਜਾਂਦਾ। critical section ਨੂੰ ਲਪੇਟੋ:

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

- **Semaphore** — ਇੱਕ counter ਜੋ *N* ਤੱਕ ਸਮਕਾਲੀ holders ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇੱਕ binary semaphore (N=1) ਇੱਕ lock ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ; ਇੱਕ counting semaphore, ਮੰਨ ਲਓ, ਇੱਕ connection pool ਨੂੰ N ਯੂਜ਼ਰਾਂ 'ਤੇ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। threads ਵਿਚਕਾਰ **signaling** (producer/consumer) ਲਈ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
- **Condition variable** — ਇੱਕ thread ਨੂੰ ਉਦੋਂ ਤੱਕ ਸੌਣ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕੋਈ predicate ਸੱਚ ਨਾ ਹੋ ਜਾਵੇ (ਜਿਵੇਂ "queue ਖਾਲੀ ਨਹੀਂ"), busy-waiting ਬਿਨਾਂ ਜਾਗਦਾ ਹੈ।
- **Atomic operations** — compare-and-swap (CAS) ਵਰਗੀਆਂ ਹਾਰਡਵੇਅਰ instructions ਜੋ read-modify-write ਨੂੰ ਅਵਿਭਾਜਿਤ ਢੰਗ ਨਾਲ ਕਰਦੀਆਂ ਹਨ, lock-free counters ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ।

## ਖ਼ਤਰੇ

Locks races ਹੱਲ ਕਰਦੇ ਹਨ ਪਰ ਨਵੇਂ ਜੋਖਮ ਲਿਆਉਂਦੇ ਹਨ: **deadlock** (threads ਇੱਕ-ਦੂਜੇ ਦੇ locks 'ਤੇ ਉਡੀਕਦੇ ਹਨ), **priority inversion**, ਅਤੇ **contention** (threads ਲੜੀਵਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, parallelism ਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੰਦੇ ਹਨ)। ਅੰਗੂਠੇ ਦਾ ਨਿਯਮ: critical sections ਨੂੰ **ਛੋਟਾ** ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾ ਕਈ locks ਨੂੰ ਇੱਕ **ਇੱਕਸਾਰ ਗਲੋਬਲ ਕ੍ਰਮ** ਵਿੱਚ ਹਾਸਲ ਕਰੋ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Concurrency bugs ਲੱਭਣ ਵਿੱਚ ਸਭ ਤੋਂ ਔਖੇ ਹੁੰਦੇ ਹਨ — ਇਹ ਅਣ-ਨਿਰਧਾਰਿਤ (nondeterministic) ਹੁੰਦੇ ਹਨ ਅਤੇ ਅਕਸਰ debugger ਹੇਠ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਇੱਕ critical section *ਪਛਾਣ* ਸਕਦੇ ਹੋ, ਸਹੀ primitive (mutex vs semaphore vs atomic) ਚੁਣ ਸਕਦੇ ਹੋ, ਅਤੇ failure modes (deadlock, contention) ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ। ਇਹ ਕਿਸੇ ਵੀ multithreaded server, ਸਾਂਝੇ cache, ਜਾਂ counter ਉੱਤੇ ਸਿੱਧੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਸਮੱਸਿਆ: ਇੱਕ race condition

ਟੂਲ

ਖ਼ਤਰੇ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ