什么是读者-写者问题？

读者-写者问题是指多个进程对一个共享资源即数据集（如文件或记录集）进行读写操作的问题。把只要求读数据的进程称为读进程，把要求修改数据的进程称为写进程。多个读进程可以同时读此数据集，不需要互斥也不会产生问题，不存在破坏数据完整性、正确性的问题，但是一个写进程不能与其他进程（不管是读进程还是写进程）同时访问此数据集，它们之间必须互斥，否则会破坏数据集的完整性。

解决读者-写者问题的意义

理论上，直接对数据集加锁，就可以实现对多进程时数据集的访问保护。但是在一段时间内并没有写进程，只有较多的读进程的话，对数据集的加锁是不必要的，反而会降低系统的性能。因此读者-写者问题的提出是为了在上述场景下，兼顾数据集访问安全和效率。

读者-写者问题的解决方法

分析

多个读进程可以并发读数据集，因此用一个变量rc记录并发读数据集的进程数。当rc≥1时，禁止写进程对数据集进行写操作，当rc=0时，允许写进程对数据集进行写操作。

rc对于读进程而言，是一个临界资源，因此设置一个互斥信号量mutex，防止多个读进程同时修改rc的值。

数据集对于写进程而言是一个临界资源，因此设置一个互斥信号量db。

相关变量总结

• mutex: 保护对rc的访问，初值为1

• db: 控制写进程对数据集的访问，初值为1

• rc: 公共变量，记录读进程的个数

同步算法

Semaphore mutex=1;  //保护对rc的访问
Semaphore db=1;  //控制对数据集的访问
int rc=0;  //读数据集的读进程个数

main()
{
  Cobegin  //两个进程并发执行
    reader();
    writer();
   Coend
}

void reader()  //读者进程
{
  while(true){
    P(mutex);  //互斥对rc的访问
    rc = rc + 1;  //增加一个读进程数
    if(rc == 1){  //当第一个读进程读数据集时，阻止写进程写
      P(db);
    }
    V(mutex);  //恢复对rc的访问
    读数据集
    P(mutex);  //互斥对rc的访问
    rc = rc - 1; //读者减少一个
    if(rc == 0){  //当最后一个读进程读完数据集时，允许写进程写
      V(db);
    }
    V(mutex);  //恢复对rc的访问
  }
}

void writer() //写者进程
{
  while(true){
    P(db);  //排斥访问数据集
    写数据集;
    V(db);  //恢复对数据集的访问
  }
}

运行分析

当一个读进程在使用数据集时，其他读进程也可以同时进行读操作，读进程的个数由rc来衡量。
此时，如果有一个写进程到来，由于rc＞0，因此写进程被挂起，知道所有读进程都结束时，写进程才可以开始写操作。

当一个写进程在写操作时，其他进程（包括读进程和写进程）都会被挂起，直到当前写进程完成。

上述算法确实可以解决读者-写者问题，当然也导致一个潜在的问题——只要有读进程陆续到来，写进程就会被一直挂起直到没有一个读进程为止，因此上述算法也被称为以读者为优先的算法。感兴趣的读者还可以查看以写者为优先的算法。

多面墙的查询问题

笔者在实现弹幕系统的过程中遇到了如下问题。

观众可以通过微信小程序发送弹幕到服务器。在服务器的数据库中，每条弹幕对应不同的记录，因此发送弹幕的请求不是互斥的。并且为了支持尽可能多的观众同时发送弹幕，发送弹幕的请求并发度需要比较高。

与此同时，有n面弹幕墙向服务器查询最新的弹幕，在某一段时间内，这n面墙应该获取到相同的弹幕。由于n的大小是未知的，让每个弹幕记录是否被某一面墙查询过是比较困难的。因此我们让每一面墙维护一个最近查询时间last_query_time，当其向服务器发送查询请求时，服务器只会返回在last_query_time之后通过审核的弹幕。因此每个弹幕只需要记录审核时间checking_time即可。

当服务器处理墙A的查询请求时，如果有新的弹幕B通过审核，则B在这次查询请求和下次查询请求中都不会返回给墙A。则弹幕B就被遗漏了。为了防止弹幕遗漏的发生，当墙A进行查询时，所有的发送弹幕请求都需要被挂起。而当有发送弹幕请求正在被处理时，所有的弹幕查询请求也需要被挂起。

多面墙的查询问题的解决

通过上述描述，读者不难发现多面墙的查询问题与读者-写者问题非常类似。
发送弹幕请求对应读进程，请求数量多，并且彼此不互斥。
查询弹幕请求对应写进程，请求数量少，并且当有查询弹幕请求时，不允许处理发送弹幕请求；当有发送弹幕请求时，不允许有查询弹幕请求。