რა არის race condition-ები და როგორ იცავენ მათგან mutex-ები და semaphore-ები?

Question

IT Interview Practice · Accepted Answer

როცა რამდენიმე thread იზიარებს მონაცემებს, მათი ოპერაციები შეიძლება გადაიხლართოს (interleave) მრავალსაფეხურიანი განახლების შუაში, რაც წარმოქმნის race condition-ს — ბაგს, სადაც შედეგი დამოკიდებულია არაპროგნოზირებად ვადებზე. Synchronization არის ხელსაწყოების ნაკრები, რომელიც აიძულებს უსაფრთხო თანმიმდევრობას.

პრობლემა: race condition

ატომურად გამოიყურება, მაგრამ სინამდვილეში read-modify-write-ია:

## პრობლემა: race condition

`count++` ატომურად გამოიყურება, მაგრამ სინამდვილეში 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** — კოდი, რომელიც ეხება გაზიარებულ მდგომარეობას და არ უნდა შესრულდეს ერთდროულად.

## ხელსაწყოები

- **Mutex (lock)** — ურთიერთგამორიცხვა: მას ერთ დროს მხოლოდ ერთი thread იჭერს; დანარჩენები იბლოკებიან მის გათავისუფლებამდე. შემოახვიეთ critical section:

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

- **Semaphore** — მთვლელი, რომელიც ერთდროულად *N* მფლობელამდე უშვებს. ბინარული semaphore (N=1) lock-ის მსგავსად მოქმედებს; მთვლელი semaphore ზღუდავს, ვთქვათ, connection pool-ს N მომხმარებელზე. ასევე გამოიყენება thread-ებს შორის **სიგნალიზაციისთვის** (producer/consumer).
- **Condition variable** — thread-ს საშუალებას აძლევს დაიძინოს, სანამ პრედიკატი ჭეშმარიტი გახდება (მაგ. „queue not empty"), busy-wait-ის გარეშე გაღვიძებით.
- **Atomic operation-ები** — hardware-ის ინსტრუქციები, როგორიცაა compare-and-swap (CAS), რომლებიც read-modify-write-ს განუყოფლად აკეთებენ, რაც lock-free მთვლელებს შესაძლებელს ხდის.

## ხაფანგები

Lock-ები race-ს აგვარებენ, მაგრამ ახალ რისკებს შემოაქვთ: **deadlock** (thread-ები ერთმანეთის lock-ებს ელოდებიან), **priority inversion**, და **contention** (thread-ები სერიალიზდებიან, პარალელიზმს კლავენ). ცერა თითის წესი: შეინახეთ critical section-ები **მოკლედ** და ყოველთვის აიღეთ რამდენიმე lock **თანმიმდევრული გლობალური რიგით**.

## რატომ არის ეს მნიშვნელოვანი

Concurrency-ის ბაგები ერთ-ერთი ყველაზე რთული აღმოსაჩენია — ისინი არადეტერმინისტულია და ხშირად ქრება debugger-ის ქვეშ. ინტერვიუერებს სურთ დაინახონ, რომ თქვენ შეგიძლიათ critical section-ის *ამოცნობა*, სწორი primitive-ის არჩევა (mutex vs semaphore vs atomic) და ხარვეზის რეჟიმებზე მსჯელობა (deadlock, contention). ეს პირდაპირ ვრცელდება ნებისმიერ მრავალ-thread-იან server-ზე, გაზიარებულ cache-ზე ან მთვლელზე.

პრობლემა: race condition

ხელსაწყოები

ხაფანგები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები