加入收藏 | 设为首页 | 会员中心 | 我要投稿 开发网_开封站长网 (http://www.0378zz.com/)- 科技、AI行业应用、媒体智能、低代码、办公协同!
当前位置: 首页 > 站长资讯 > 外闻 > 正文

源码解析之锁

发布时间:2021-04-09 12:56:36 所属栏目:外闻 来源:互联网
导读:持有读锁,说明当前肯定没有正在写的写者,但是可能有等待写的写者和等待读的读者(因为有等待写的写者导致无法加锁成功)。当释放读锁时,如果还有其他读者,则其他读者可以继续持有锁,因为读者可以共享读锁,而写者保持原来状态。如果这时候没有读者但是有
持有读锁,说明当前肯定没有正在写的写者,但是可能有等待写的写者和等待读的读者(因为有等待写的写者导致无法加锁成功)。当释放读锁时,如果还有其他读者,则其他读者可以继续持有锁,因为读者可以共享读锁,而写者保持原来状态。如果这时候没有读者但是有等待写的写者,则从队列中选择第一个节点成为锁的持有者,其他的写者则继续等待,因为写者不能共享写锁。持有写锁,可能有等待写的写者和等待读的读者。这里是读者优先持有锁,因为读者可以共享持有锁,提高并发,如果没有读者,则再判断写者。

总结:单纯的互斥锁是比较简单的,读写锁就相对复杂一点,主要是要根据读锁和写锁的特性制定一些策略,比如避免饥饿问题。libtask的方式是,加写锁的时候,当无法持有锁的时候,申请者就会被插入等待等待队列。这个是没有什么好说的,加读者的时候,情况就复杂了点,如果这时候有读者正在持有锁,理论上,申请者也可以持有锁,因为读锁是共享的,但是单纯这样处理的话,可能会导致等待写的写者一直拿不到锁,所以这里需要判断是否有等待写的写者,如果有则当前申请者则不能再持有读锁,而是要加入等待队列。那么在释放锁的时候,当释放读锁时,优先让等待写的写者持有锁,再到等待读的读者持有锁。同样,当释放写锁时,优先让读者持有锁,这样就能比较好地平衡读者和写者持有锁的机会。

(编辑:开发网_开封站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读