操作系统 day17(读者-写者问题、哲学家进餐问题、管程)

读者-写者问题

  1. 分析
    在这里插入图片描述
  2. 读者优先的代码实现
    在这里插入图片描述
  • 若不对count采用互斥操作,那么会导致读者进程之间存在:某个读者进程阻塞在P(rw)中,且它需要等到最后一个读者进程解锁V(rw)才能被唤醒,这很影响系统效率,如果我们对count进行互斥操作,那么读者进程只会阻塞在第一步的P(mutex),并且在下一个V(mutex)时就会被唤醒。

3.读写公平的代码实现
在这里插入图片描述

  • 在这种算法中,连续写入的多个读进程可以连续访问,且不会让写进程饥饿
  1. 核心
  • 设置计数器count,来记录当前访问共享文件的读进程数,并根据count的值来判断当前的读进程是否是第一个/最后一个,再做相应处理。
  • 对count变量的检查和赋值不能一气呵成,所以采用互斥信号量。
  • 复杂的互斥问题,使用读者-写者算法。同步问题,使用生产者-消费者算法

哲学家进餐问题

  1. 分析
    在这里插入图片描述
  • 会产生死锁的代码
    在这里插入图片描述
  • 防止死锁的想法
    在这里插入图片描述
    在这里插入图片描述
  1. 第三种方法的代码实现
    在这里插入图片描述
  • 由于哲学家进程需要同时持有两个临界资源,就有了“死锁”问题的隐患。
  • 因此,如果遇到了一个进程需要同时持有多个临界资源,就应该参考哲学家问题,分析是否会发生死锁。

管程

在这里插入图片描述

  1. 基本特征
  • 各外部进程/线程只能通过管程提供的特定“入口”才能访问共享数据
  • 每次仅允许一个进程在管程内执行某个内部过程
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

丿罗小黑

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

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

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

打赏作者

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

抵扣说明:

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

余额充值