《操作系统》-读者-写者问题

什么是读者-写者问题?

有读者和写者两组并发进程,共享一个文件,当两个或两个以上的读进程同时访问共享数据时不会产生副作用,但若某个写进程和其他进程(读进程或写进程)同时访问共享数据时则可能导致数据不一致的错误。因此要求:①允许多个读者可以同时对文件执行读操作;②只允许一个写者往文件中写信息;③任一写者在完成写操作之前不允许其他读者或写者工作;④写者执行写操作前,应让已有的读者和写者全部退出
在这里插入图片描述

分析读者-写者问题

互斥关系
写进程和写进程访问共享数据时互斥
写进程和读进程访问共享数据时互斥

如何实现

我们先来看看这种算法

semaphore rw=1; //用于实现对共享文件的互斥访问
int count = 0; //记录当前有几个读进程在访问文件
semaphore mutex = 1;//用于保证对count变量的互斥访问

写者

writer (){
while(1){
P(rw); //写之前“加锁”
写文件…
V(rw); //写完了“解锁” } }

读者

reader (){
while(1){
P(mutex); //各读进程互斥访问count
if(count==0) //由第一个读进程负责
P(rw); //读之前“加锁”
count++; //访问文件的读进程数+1
V(mutex);
读文件…
P(mutex); //各读进程互斥访问count
count--; //访问文件的读进程数-1
if(count==0) //由最后一个读进程负责
V(rw); //读完了“解锁”
V(mutex);
} }

思考:这种算法是否有缺陷呢?
问题1:若两个读进程并发执行,则count = 0时两个进程也许都能满足if条件 都会执行p(rw),从而使第二个读进程阻塞的情况。那这种问题又该如何解决呢?
首先我们应当分析出现上述问题的主要原因在于对count变量的检查和赋值无法一气呵成,因此可以设置一个互斥信号量来确保对count变量的检查和赋值操作是互斥的。

问题二:读文件可以同时进行,并且会使临界资源的访问互斥,如果有读进程源源不断的进行读文件,那写进程就有可能出现“饿死”的情况,那我们该如何解决这种情况呢?
使算法里面读进程优先即可

算法改进后

semaphore rw=1; //用于实现对共享文件的互斥访问
int count = 0; //记录当前有几个读进程在访问文件
semaphore mutex = 1; //用于保证对count变量的互斥访问
semaphore w = 1; //用于实现“写优先”

读者

writer (){
while(1){
P(w);
P(rw);
写文件…
V(rw);
V(w);
} }

写者

reader (){
while(1){
P(w);
P(mutex);
if(count==0)
P(rw);
count++;
V(mutex);
V(w);
读文件…
P(mutex);
count--;
if(count==0)
V(rw);
V(mutex);
} }

这种算法中,连续进入的多个读者可以同时读文件,写者和其他进程不能同时访问文件;写者不会饥饿,但也不是真正的“写优先”而是相对公平的先来先服务

读者-写者问题的核心思想在于设置一个计数器count用来记录当前正在访问的读进程数,我们可以用count来判断当前进程是否为第一个或者最后一个读进,从而做出不同的处理。
另外,对count变量的检查和赋值不能一气呵成导致了一些错误,如果需要实现“一气呵成”自然要想到互斥信息量
最后,我们还应该认真体会该问题中我们是如何解决“写进程饥饿”问题的

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

电脑小白路过

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值