读者写者问题详解 · 融合风（象牙 + Obsidian 入口）

速查

多个读者和写者共享一个文件：读-读允许，读-写互斥，写-写互斥。需要 rw=1（读写互斥）、mutex=1（保护 count）、count（读者数）。读者优先可能饿死写者。

速查 ▾

多个读者和写者共享一个文件（数据库）：

读者优先方案（写者可能饥饿）：

写者：P(rw); 写文件; V(rw)
读者：P(mutex); count++; if(count==1) P(rw); V(mutex);
      读文件;
      P(mutex); count--; if(count==0) V(rw); V(mutex)

写者优先方案：增加信号量 w=1，写者到来时先 P(w) 阻止新读者进入，避免写者饥饿。

读者优先，初始 $rw=1, mutex=1, count=0$，到达顺序 R1, R2, W1, R3：

步骤	操作	rw	mutex	count	说明
1–4	R1 加锁文件	0	1	1	第一个读者锁 rw
6–9	R2 加入	0	1	2	R1、R2 同时读
10	W1 P(rw)	-1	1	2	W1 阻塞
11–13	R3 也能加入	-1	1	3	R3 开始读

写者 W1 被读者们"饿"住——这就是读者优先的饥饿问题。

count 保护必要性若不用 mutex 保护 count：R1、R2 并发 count++ 都读到 0 写回 1，实际 2 读者却记成 1；R1 结束时 count--→0 会错误地 V(rw)，导致写者混入→互斥被破坏。

注意

必背

与生产者消费者核心区别？

生产者消费者全互斥；读者写者允许多读者并发，仅写者独占。

count 的作用？为何需 mutex？

count 记录读者数；首读者加锁、末读者解锁。mutex 保证 count 原子修改。

为何读者优先饿写者？

count>0 时新读者不断加入，写者 P(rw) 一直无法通过，直到所有读者退出。

写者优先如何防饥饿？

增加 w 信号量：写者持 w 时新读者在 P(w) 阻塞，不无限加入。

能否一个信号量实现？

不能。需用 count 跟踪读者数配合额外信号量。

点击「读者进入」观察 count 增长、首个读者锁文件；「写者进入」在读者在场时会被阻塞（读者优先饥饿）

读-读允许；读-写/写-写互斥。count 用 mutex 保护