尧图网站建设 尧图网络
  • 首页
  • 关于我们
  • 服务项目
  • 案例展示
  • 建站流程
  • 资讯中心
  • 联系我们
首页/资讯中心/详情

基于读写锁的读者写者问题

基于读写锁的读者写者问题
📅 发布时间:2026/7/31 2:48:36

读者写者模式

读写锁

在编写多线程的时候,有一种情况是十分常见的。那就是,有些公共数据修改的机会比较少。相比较改写,它们读的机会反而高的多。通常而言,在读的过程中,往往伴随着查找的操作,中间耗时很长。给这种代码段加锁,会极大地降低我们程序的效率。那么有没有一种方法,可以专门处理这种多读少写的情况呢? 有,那就是读写锁。
读者和读者之间无互斥关系,可并行访问;
读者和写者之间是互斥关系,一方操作时另一方必须等待;
写者和写者之间也是互斥关系。

读写锁原理细节:

第一个到达的读者需要加锁,阻止写者进入; 后续新来的读者直接进入读取,计数累加; 最后一个读完的读者释放锁,写者才有机会写入。

读写锁接口

设置读写优先

int pthread_rwlockattr_setkind_np(pthread_rwlockattr_t *attr, int pref); /* pref 共有 3 种选择 PTHREAD_RWLOCK_PREFER_READER_NP (默认设置) 读者优先,可能会导致写者饥饿情况 PTHREAD_RWLOCK_PREFER_WRITER_NP 写者优先,目前有 BUG,导致表现行为和 PTHREAD_RWLOCK_PREFER_READER_NP 一致 PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP 写者优先,但写者不能递归加锁 */
初始化
int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock,const pthread_rwlockattr_t *restrict attr);

销毁:

int pthread_rwlock_destroy(pthread_rwlock_t *rwlock);
加锁和解锁
int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock); int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock); int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);

读者优先:

只要有读者正在读,后续新来的读者全都可以插队进入读取;写者会一直被阻塞,极易写者饥饿(写者迟迟得不到执行机会)。

共用基础变量:read_count:正在读的读者数量,初值 = 0mutex:保护 read_count 的互斥锁wrt:读写共用锁(写者占用后,任何人都进不来)

一、读者优先

核心思想

只要有读者正在读,后续新来的读者全都可以插队进入读取;写者会一直被阻塞,极易写者饥饿(写者迟迟得不到执行机会)。

共用基础变量:read_count:正在读的读者数量,初值 = 0

mutex:保护 read_count 的互斥锁

wrt:读写共用锁(写者占用后,任何人都进不来)

执行逻辑

  1. 读者到来:
    • 先抢占 mutex 锁,修改 read_count
    • 若自己是第一个读者:抢占 wrt 锁(锁住资源,不让写者进来)
    • read_count++,释放 mutex,开始读文件
  2. 读者离开:
    • 抢占 mutex,read_count--
    • 若自己是最后一个读者:释放 wrt 锁,写者才有资格竞争资源
    • 释放 mutex
  3. 写者到来: 直接申请 wrt 锁,拿不到就阻塞; 只要还有读者在读,wrt 永远不会释放,写者持续等待。

优缺点

✅ 读者效率极高,并发读取顺畅 ❌ 致命缺陷:写者饥饿

二:写者优先:

核心思想

一旦有写者等待资源,后续所有新来的读者全部阻塞排队;必须等所有等待 + 正在执行的写者全部完成后,读者才能继续读。 杜绝写者饥饿,但会出现读者饥饿。

新增变量:write_wait:等待中的写者数目read_queue:读者等待队列

执行逻辑

  1. 只要存在等待的写者:拒绝所有新读者入场
  2. 写者到达优先级 > 新来读者
  3. 所有排队写者依次写完,资源空闲后,才放行积压的读者

优缺点

✅ 写者不会饿死,写入响应快 ❌ 大量读者堆积等待,读者饥饿

三、公平读写(队列先来先服务 FIFO,无饥饿)

核心思想

按照进程到达的先后顺序排队,严格遵循先来后到:

  1. 排在队列首位的进程获得资源使用权
  2. 若队首是读者:连续放行队列里紧随其后的所有读者一起读
  3. 若队首是写者:只允许这一个写者独占资源,写完才轮到下一批进程

效果

读者、写者地位均等,既不会读者饥饿,也不会写者饥饿,整体吞吐最均衡。

相关新闻

  • 嵌入式开发必知:USART、IIC、SPI、485、CAN五大通讯协议核心对比与实战选型
  • WorkBuddy 三种工作模式详解:Craft、Plan、Ask 如何掌控 AI 自主权
  • GB/T 14710-2009是什么?医用设备必过的 “魔鬼环境试炼”

最新新闻

  • 基于51单片机的烟雾报警系统:从传感器原理到智能算法实现
  • 赛马娘角色反应集制作指南:从素材收集到社区传播
  • UE5粒子特效LOD优化实战:三步解决性能瓶颈,兼顾视觉与帧率
  • OpenUtau:开启你的虚拟歌手创作之旅,从零到一的音乐魔法
  • Unity游戏实时翻译实战:基于XUnity.AutoTranslator的本地化解决方案
  • DroidCam实战:将手机变身高清PC摄像头,低成本提升视频画质

日新闻

  • 7步掌握KMS智能激活工具:Windows和Office永久激活完整方案
  • 如何在Windows上运行iOS应用:ipasim跨平台模拟器终极指南
  • 2026年重庆工伤赔偿律师口碑推荐:洪家木律师用专业赢得信赖 - 本地品牌推荐

周新闻

  • 大连理工大学与东京大学联手打造的“主动型AI助手“
  • 170.2026年国家级科研瓶颈:超精密单点金刚石切削(SPDT)光学表面生成
  • SongBloom:革命性歌曲生成框架深度解析——如何通过交织自回归与扩散模型创作完整音乐

月新闻

  • 2026年6月公司网站搭建最新热门渠道测评:四大低成本/零代码平台对比+避坑
  • 【Linux】Linux arm 编译QT程序,出现expected “}“报错
  • 【MATLAB例程】四基站二维AOA定位与距离辅助增强对比仿真。基于角度观测和测距修正的固定目标平面定位精度分析

关于尧图

  • 公司简介
  • 团队介绍
  • 企业文化
  • 荣誉资质

服务项目

  • 定制开发
  • 电商建站
  • UI 设计
  • 运维服务

快速链接

  • 案例展示
  • 建站流程
  • 常见问题
  • 资讯中心

联系方式

  • 📍北京市朝阳区互联网产业园 A 座 10 层
  • 📞400-888-8888
  • ✉️contact@rkmt.cn
  • 🕐周一至周日 9:00-21:00

© 2024 北京尧图网络科技有限公司 版权所有 | 京 ICP 备 XXXXXXXX 号