首页UC › OS: 读者写者问题(写者优先+LINUX+多线程+互斥量+代码)

OS: 读者写者问题(写者优先+LINUX+多线程+互斥量+代码)

一. 引子

最近想自己写个简单的 WEB SERVER ,为了先练练手,熟悉下在LINUX系统使用基本的进程、线程、互斥等,就拿以前学过的 OS 问题开开刀啦。记得当年学读者写者问题,尤其是写者优先的时候,那是真心纠结啊。刚才还觉得理解了,过一会儿又糊涂了。现在重新再看,还是容易纠结。没办法,用得少。我把读者优先和写者优先都实现了一下。选择性重看了小部分《unix高程》使用了多线程+互斥量实现。

二. 互斥量与信号量

互斥量如其名,同一时间只能被一个线程占有,实现线程间对某种数据结构的互斥访问。试图对一个已经加锁的互斥量加锁,会导致线程阻塞。允许多个线程对同一个互斥量加锁。当对互斥量解锁时,阻塞在该互斥量上的线程会被唤醒,它们竞争对该互斥量加锁,加锁成功的线程将停止阻塞,剩余的加锁失败于是继续阻塞。注意到,谁将竞争成功是无法预料的,这一点就类似于弱信号量。(强信号量把阻塞在信号量上的进程按时间排队,先进先出)

互斥量区别于信号量的地方在于,互斥量只有两种状态,锁定和非锁定。它不像信号量那样可以赋值,甚至可以是负值。共性方面,我所体会到的就一句话,都是用来实现互斥的。至于其它区别或联系,用不上,不作研究。

三. 读者优先

只要有一个读者正在读,那么后续的读者都能立即读,不管有多少写者在等待。可能导致写者饥饿。

1. 读者

1) 写者写时,不可读
2) 有别的读者正在读,可读

2. 写者

1) 有读者正在读,不可写
2) 有写者正在写,不可写
3) 无读者正在读,无写者正在写,可写

四. 写者优先

当新的写者希望写时,不允许该写者后续的读者访问数据区,但必须保证之前的读者读完。

1. 读者特点

1) 有写者正在写或者等待写,须等到没有写者才能读
2) 没有写者,可以读

2. 写者特点

1) 写者与写者互斥。当其它写者正在写时,其它写者不能写。
2) 写者与读者互斥。之前只有读者在读,当写者出现时,必须等到之前的读者都读完才能写。这尊重了之前读者的意愿。
3) 写者可以有条件地插读者的队。当前有写者正写,有读者在等,这时来了新写者,新写者可以在那些读者之前执行。这不尊重

3. 写者实现

首先,写者的代码应该是这样一种形式,才能保证同一时刻只有一个写者修改数据:

考虑到写者对读者的影响是:当任何写者想写时,读者都必须被阻塞;并且,写者阻塞了读者并停止阻塞之前,后续的任何写者都会优先于读者执行。这就如同有一个写者队列,当第一个写者入队时,读者完全被阻塞,直到最后一个写者离开队列。
据此,可以用 writerCnt 来统计写者的数量,而用互斥量 accessWriterCnt 来互斥各线程对 writerCnt 的访问。代码应作如下调整:

4. 读者的实现

读者的实现首先必须保证支持多个读者同时读,因此下面的代码不合适:

在上面的实现中,很明显的问题是,当一个读者执行 read() 的同时,不可能有另外的读者进入临界区并执行 read() 函数了。因此,必须确保在执行 read() 函数之前对readerLock解锁。代码类似于:

于是乎,现在我们可以注意到,假如写者率先锁定了 readerLock , 那么后续的读者被阻塞在 pthread_mutex_lock(&readerLock); 了,这点很正确。在写者最终释放 readerLock 之前,可能有成千上万的读者都被阻塞在 readerLock 上, readerLock 释放之后,这些读者会竞争这 readerLock,嗯,这没什么问题。问题在于,此后,将可能有新的写者有写需求并希望获得这把锁(参照一下写者代码吧),那么,此时,写者不得不和成千上万的读者一起竞争 readerLock,由于将占有 readerLock 的人使随机的,写者在数量上不占优势,将进入饥饿状态。因此,这种实现无法满足“写者优先”的需求。
通过添加另一个互斥量,我们可以把写者的这些成千上万的竞争者不再竞争 readerLock ,下面的方案里,当读者释放锁时,假如写者想获得这把锁,那么它能立即得到。

为了防止执行 read() 的同时,写者正在执行 write(),所以,有必要在读者的代码中,等待 write() 函数执行完,注意到写者的代码中,使用writeLock 互斥量来保护数据:

因而,读者也可以通过对 writeLock 加锁以保证读的时候没有同时写,但是下面这种做法又导致读者无法并发:

我们需要更合理地安排 lock(&writeLock) 的位置,并且需要避免每个读者都对 writeLock 加锁,即,只让某个读者对 writeLock 加锁,同时还保证读的时候,没有写者在写。
注意到,假如有多个读者并发地执行 read() 函数,那么,只要在第一个读者开始读之前锁住 writeLock 在最后一个读者执行 read() 之后解锁 writeLock,就可以解决读者并发的问题。
我们需要为读者添加两段代码:
代码段1:

代码段2:

代码段2 明显应该放在 read()函数之后;

经典的做法是把代码段1放到位置2,如果是这样,那么代码如下,我故意用了很多块作用域(用花括号{}表示)来凸显临界区:

如此布局的意义在于,必须放在 lock(&readerLock) 和 unlock(&readerLock) 之间锁定 writeLock 。否则,一旦读者释放了 readerLock ,后续的写进程(如果有)可能会率先获得 writeLock 锁,从而导致比读者后发生的写者先执行。
提示:读者在lock(&readerLock) 和 unlock(&readerLock) 之间锁定 writeLock 是绝对不会阻塞的。因为读者已经占据了 readerLock 互斥量,这意味着,即便有写者,它也不可能已经占据了 writeLock 锁。
将片段1放在其它位置 无法起到这种效果。但我觉得这么做没啥意义,因为会导致代码本身的矛盾:
1)按照老 写者、读者、新写者的出现顺序,假设新写者出现时,老写者还没完(此时读者是阻塞的),那么新写者就可以打破顺序,优先于读者执行。
2)按照 读者、写者的出现顺序,假设写者出现时读者还没完,那代码会要求必须等读者执行完。

与其做作地无意义,不如淫荡地统一。

5. 运行结果

频率调高时,眼花缭乱,我把输出重定向到文件里,然后使用 cat data.out | uniq 去除一些重复的输出,虽然不能说明代码正确,不过没有看到错误~
read 0
write 383
write 886
read 886
write 777
write 915
read 915
write 793
write 335
read 335

没出现什么乱子

嗯,该睡了,不喜熬夜。

附录.

1. 读者优先代码

2. 写者优先代码

发表评论