读者写者分析

/*
读者, 写者问题, 读者优先
 */
 

 /*
 读者的伪代码, rmutex初始值为1, wmutex为1
  */

while(true)
    p(rmutex); //用于是读进程互斥地访问共享变量readcount
    if(readcount == 0)
        p(wmutex);   //如果是第一个读者且优先于写者执行到此处,那么就需要互斥写者

    readcount++; //对readcount进行操作
    v(rmutex);   //操作完之后释放信号量

    /*
    临界区
     */

    p(rmutex); //由于又要对readcount变量进行操作
    readcount--;
    if(readcount == 0)
        v(wmutex);  //如果此时是最后一个读者, 那么就需要给wmutex加1, 唤醒写者
    v(rmutex);      //结束对readcount变量的访问


/*
写者的伪代码, wmutex = 1
 */
while(true)
    p(wmutex);
    /*
    临界区
     */
    v(wmutex);

我们分析一种情况, 假设来了一个读者加写者
读者先执行到 if(readcount == 0)这里, 执行完之后 rmutex = 0, wmutex = 0;
此时写者刚刚执行到 p(wmutex) 所以 wmutex = -1, 根据信号量的定义, 此时写者就开始一直在这里等待了

假设此时读者进入了临界区,还没有退出来, 所以 rmutex = 1, wmutex = -1;
又来了一个读者, 它对rmutex操作, rmutex = 0, readcount = 2;
第二个读者也进入了临界区, rmutex = 1, readcount = 2;(所以实现了多个读者)

这个模型还是存在一定的问题的, 如果第一个读者执行到if(readcount == 0)这个时候, 同时来一了个读者和写者, 由于此时读者还在访问readcount变量, 所以第二个读者是无法进入的, 然而由于第一个读者释放了wmutex, 这就会导致写者先于读者进入, 所以这个模型所谓的读者有先, 必须是readcount变量记录的才能优先

写者优先的模型演变
第一个写者优先的模型
/*
先看读者
 */

P(mutexReadCount);
P(r);
readcount++;
V(r);
V(mutexReadCount);

/*
reading
 */
P(mutexReadCount);
readcount--;
V(mutexReadCount);

毫无疑问, mutexReadCount 信号量是为了读者之间互斥地访问readcount变量的

所以mutexReadCount 信号量的初始值为1

r可以理解成申请读

这时候看一下写者

P(mutexWriteCount);
writecount++;
if(writecount == 1)
    P(r); //作为写者去申请一个读资源, 所以r这个信号量是为了互斥读者与写者的
V(mutexReadCount);

P(w);
/*
Writing...
 */

V(w);

P(mutexWriteCount);
writecount--;
if(writecount == 0)
    V(r);
V(mutexWriteCount);

这一个写者的逻辑其实也很明显,那么有什么问题呢?

我们考虑一个读者先进来,
初始: mutexReacCount = 1, r = 1, w = 1;

如果读者进入了临界区, 此时读者显然已经释放了mutexReadCount 和 r
所以, 如果这时候一个写者进来了, 显然它是可以一直走下去的

也就是说两者同时进入了临界区。

第二个写者优先模型
10651191-c11b44bc5d011cbb.png
第二种
/*
读者
 */

P(mutexReadCount);
P(r);
readcount++;

if(readcount == 1)
    p(w);

V(r);
V(mutexReadCount);

/*
reading
 */

P(mutexReadCount);
readcount--;
if(readcount == 0)
    V(w);
V(mutexReadCount);

显然这里多加了一层判断,如果是第一个读者, 就要互斥写者
而写者并没有修改

然后我们来分析一下

还是考虑读者最先进来, 初始值 mutexReadCount = 1, r = 1, w = 1;
假设第一个读者进入了临界区, 此时 mutexReadCount = 1, r = 1, w = 0, readcount = 1;
然后这时候一个写者进来了,
它肯定会停留在P(w)这里, 也就是说此时的信号量 mutexReadCount = 1, r = 0, w = -1;

然后这个时候读者还在临界区,第二个读者过来了
因为此时的r = 0,
所以第二个读者会停在 P(r)这里,此时信号量 mutexReadCount = 0(因为第二个读者消耗了这个资源), r = -1, w = -1;

然后这个时候第一个读者想要退出临界区, 它就会尝试去 P(mutexReadCount), 然后mutexReadCount = -1,所以第一个读者是出不去的,

这就形成了一个比较有趣的局面, 第一个写者进不了临界区, 因为第一个读者还在临界区, 第一个读者出不了临界区, 因为第二个读者正在尝试进来, 第一个读者无法修改readcount的值。

三个进程形成的死锁还是比较有趣的, 当然也比较难分析。

第三个写者优先模型

既然第二个写者优先模型会导致三个进程形成死锁, 问题其实主要出现在第二个读者和第一个读者, 我只需要让第二个读者进不来进行了。

10651191-7265c0d322bc1f21.png
第三种

于是我们这样想

/*
读者
 */

P(r);
P(mutexReadCount);
readcount++;

if(readcount == 1)
    p(w);


V(mutexReadCount);
V(r);

/*
reading
 */

P(mutexReadCount);
readcount--;
if(readcount == 0)
    V(w);
V(mutexReadCount);

也就是说我们把P(r)和P(mutexReadCount)的顺序调了一下,这样第二个读者在第一个读者还在临界区的时候进来

此时 r = 0, w = -1, mutexReadCount = 1;

所以第二个读者就会停在P(r)处, 此时的信号量为 r = -1, w = -1, mutexReadCount = 1;
所以第一个读者还是可以出去的。

ok那这个模型还有什么问题呢?

这时候我们想想如果是第一个写者先进入临界区,
此时信号量 w = 0, r = 0, writecount = 1;
所以第一个读者会被堵在 P(r)处

如果这个时候第二个写者进来了,
那么它会使得writecount++, 也就是writecount = 2,
但是还是会被堵在P(w)这里
所以这个时候当第一个写者退出的时候, 第二个写者又进来了

ok这个时候好像还是没有问题

如果是第一个写者在退出的时候恰好在修改writecount变量, 那么这个时候第二个写者就被堵在了P(mutexWriteCount)这里
而writecount = 1, 所以第一个写者就会唤醒还在排队的第一个读者。
ok这个时候读者就会开始它的表演, 由于它是第一个读者, 所以它会互斥写者,也就是w = 0,
所以这个时候先到的写者就只能骂娘了, 明明我到的比你早, 结果还被你堵住了。。
当然如果没有后续的读者进来的话, 那么这个时候第一个读者退出临界区的时候就会唤醒那个在骂娘的写者

ok? 到这里好像还是没有问题啊。。。难道是我记错了??

哦哦,好像老师的解释是: 如果有大量的读者, 那写者就会一直等下去了。。。所以这个模型没有体现出写者该有的优先权

okoko我们来看看最后的一个模型

写者优先的实现

10651191-1851a500c02c9342.png

这里设置了5个信号量

其中 mutexReadCount是用来互斥地修改readcount这个变量的
wr都是用来互斥读者和写者地

还有一个 mutexPriority是用来报障优先权的

那到底是怎么保障的呢?

如果持续不断地有读者进来, 这时候我们假设

第一个读者已经进入了临界区, 而第一个写者在P(w)处等待

此时 mutexPriority = 1, r = 0

说实话我不懂为啥这个体现了优先级

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值