race condition คืออะไร และ mutex กับ semaphore ป้องกันมันอย่างไร?

Question

IT Interview Practice · Accepted Answer

เมื่อหลายเธรดใช้ข้อมูลร่วมกัน การทำงานของพวกมันสามารถ แทรกสลับ (interleave) เข้าไปกลางคันของการอัปเดตหลายขั้นตอน ทำให้เกิด race condition — บั๊กที่ผลลัพธ์ขึ้นอยู่กับจังหวะเวลาที่คาดเดาไม่ได้ การซิงโครไนซ์ (synchronization) คือชุดเครื่องมือที่บังคับให้เกิดลำดับที่ปลอดภัย

ปัญหา: 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** — โค้ดที่แตะสถานะร่วมและต้องไม่ทำงานพร้อมกัน

## เครื่องมือ

- **Mutex (lock)** — การกีดกันร่วม (mutual exclusion): มีเพียงเธรดเดียวที่ถือมันได้ในแต่ละช่วงเวลา เธรดอื่นจะถูกบล็อกจนกว่ามันจะถูกปล่อย ครอบ 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 ผู้ใช้ ยังใช้เพื่อ **ส่งสัญญาณ (signaling)** ระหว่างเธรดได้ด้วย (producer/consumer)
- **Condition variable** — ให้เธรดหลับจนกว่าเงื่อนไข (predicate) จะเป็นจริง (เช่น "คิวไม่ว่าง") แล้วปลุกโดยไม่ต้อง busy-wait
- **Atomic operation** — คำสั่งฮาร์ดแวร์อย่าง compare-and-swap (CAS) ที่ทำ read-modify-write แบบแบ่งแยกไม่ได้ ทำให้สร้างตัวนับแบบ lock-free ได้

## กับดัก

Lock แก้ปัญหา race แต่ก็นำความเสี่ยงใหม่เข้ามา: **deadlock** (เธรดต่างรอ lock ของกันและกัน), **priority inversion**, และ **contention** (เธรดกลายเป็นทำงานเรียงลำดับ ทำลายความขนาน) กฎง่าย ๆ คือ ให้ critical section **สั้น** ไว้ และจับ lock หลายตัวตาม **ลำดับ global ที่สอดคล้องกัน** เสมอ

## ทำไมจึงสำคัญ

บั๊กเกี่ยวกับ concurrency เป็นหนึ่งในบั๊กที่หายากที่สุดในการหา — มันไม่เป็นแบบกำหนดได้ (nondeterministic) และมักหายไปเมื่ออยู่ใต้ debugger ผู้สัมภาษณ์อยากเห็นว่าคุณสามารถ *มองออก* ว่าตรงไหนเป็น critical section เลือก primitive ที่ถูกต้อง (mutex vs semaphore vs atomic) และให้เหตุผลเกี่ยวกับโหมดความล้มเหลว (deadlock, contention) ได้ สิ่งนี้ใช้ได้โดยตรงกับเซอร์วิสหลายเธรด, cache ที่ใช้ร่วมกัน, หรือตัวนับใด ๆ

ปัญหา: race condition

เครื่องมือ

กับดัก

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง