Race condition là gì, và mutex với semaphore ngăn chúng ra sao?

Question

IT Interview Practice · Accepted Answer

Khi nhiều thread dùng chung dữ liệu, các thao tác của chúng có thể xen kẽ (interleave) vào giữa một cập nhật nhiều bước, tạo ra một race condition — một bug mà kết quả phụ thuộc vào thời điểm khó lường. Đồng bộ hóa (synchronization) là tập hợp các công cụ ép ra thứ tự an toàn.

Vấn đề: một race condition

trông có vẻ nguyên tử (atomic) nhưng thực chất là đọc-sửa-ghi (read-modify-write):

## Vấn đề: một race condition

`count++` trông có vẻ nguyên tử (atomic) nhưng thực chất là đọc-sửa-ghi (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         ┘
```

Khoảng cửa sổ giữa lúc đọc và lúc ghi là một **critical section** (vùng tới hạn) — đoạn code chạm vào trạng thái dùng chung và không được chạy đồng thời.

## Các công cụ

- **Mutex (lock)** — loại trừ tương hỗ: chỉ một thread giữ nó tại một thời điểm; các thread khác bị chặn cho tới khi nó được nhả. Bọc lấy critical section:

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

- **Semaphore** — một bộ đếm cho phép tối đa *N* thread giữ đồng thời. Semaphore nhị phân (N=1) hoạt động như một lock; semaphore đếm giới hạn, chẳng hạn, một connection pool ở mức N người dùng. Cũng dùng để **báo hiệu (signaling)** giữa các thread (producer/consumer).
- **Condition variable** — cho một thread ngủ cho tới khi một điều kiện trở thành đúng (ví dụ "queue không rỗng"), thức dậy mà không cần busy-wait.
- **Atomic operation** — các lệnh phần cứng như compare-and-swap (CAS) thực hiện đọc-sửa-ghi một cách không thể chia cắt, cho phép các bộ đếm lock-free.

## Cạm bẫy

Lock giải quyết race nhưng lại đưa vào rủi ro mới: **deadlock** (các thread chờ lock của nhau), **priority inversion** (đảo ưu tiên), và **contention** (tranh chấp — các thread bị tuần tự hóa, triệt tiêu tính song song). Quy tắc ngón tay cái: giữ critical section **ngắn**, và luôn giành nhiều lock theo một **thứ tự toàn cục nhất quán**.

## Tại sao điều này quan trọng

Bug đồng thời (concurrency) thuộc loại khó tìm nhất — chúng phi tất định và thường biến mất khi chạy debugger. Người phỏng vấn muốn thấy bạn có thể *nhận ra* một critical section, chọn đúng primitive (mutex vs semaphore vs atomic), và lý giải các chế độ hỏng (deadlock, contention). Điều này áp dụng trực tiếp cho bất kỳ server đa luồng, cache dùng chung, hay bộ đếm nào.

Vấn đề: một race condition

Các công cụ

Cạm bẫy

Tại sao điều này quan trọng

Câu hỏi liên quan