设为首页 收藏本站
查看: 377|回复: 0

[经验分享] Linux内核RCU(Read Copy Update)锁简析-前传

[复制链接]
累计签到:1 天
连续签到:1 天
发表于 2015-7-13 08:33:16 | 显示全部楼层 |阅读模式
如果你用Linux perf tool的top命令做热点纠察时,你会发现,前10名嫌疑犯里面肯定有好几个都是锁!
在进行并行多处理时,不可 避免地会遇到锁的问题,这是不可避免的,因为这一直以来也许是保护共享数据的唯一方式,被保护的区域就是临界区。而我们知道,锁的开销是巨大的,因为它不 可避免地要么等待,要么让别人等待,然而这并不是开销的本质,开销的本质在于很多锁都采用了“原子操作”这么一个技术,如此一个原子操作会对总线或者 cache一致性造成很大的影响,比如要对一个变量进行原子加1,不要认为它很简单,其实背后会有很多不希望的操作,在某架构的处理器上,首先要LOCK 总线,这意味着LOCK不解除期间,其它处理器不能访存(起码是内存的某些区域),可能还要涉及到刷cache,或者触发cache一致性操作...这还 不算最猛的打击,在某些架构上,存在内存栅栏,它会刷掉CPU的流水线,刷掉cache,几乎所有的为优化而设计的方案全部失效,当然,这是代价,收益就 是你保护了临界区。
       你要保护临界区,你要付出代价,这个代价如果用复杂的锁来支付的话,未免有点大。非要这样子吗?也许是你的数据结构设计地不好,也许是你的代码流设计地不 好,比如多个线程同时读共享数据,两个线程一个读一个写,能否采用环形缓冲区来减轻竞争呢?事实上很多诸如网卡,硬盘等共享外设驱动程序都是这么玩的,代 码只要保证读指针和写指针不相互超越即可,这样可以最小化锁的使用,当然这只是一个非常简单的例子。

       设计好的数据结构和代码流程是一方面,但是这个层次不够抽象,更好的方式就是设计一种更加优化的锁。读写锁这种不对称的锁应对读者多写者少的情景是一种优 化的锁,它对读者的优待就是无需等待,只要没有写者就可以直接读,否则才等待。而对于写者,它需要等待所有读者的完成。这种读写的实现可以依赖于另一种叫 做自旋锁的机制实现,我的一个实现如下所示:

typedef struct {

    spinlock_t *spinlock;

    atomic_t readers;

}rwlock_t;
static inline void rdlock(rwlock_t *lock)
{
    spinlock_t *lck = lock->spinlock;
    if (likely(!lock->readers++))
        spin_lock(lck);
}

static inline void rdunlock(rwlock_t *lock)
{
    spinlock_t *lck = lock->spinlock;
    if (likely(!--lock->readers))
        spin_unlock(lck);
}

static inline void wrlock(rwlock_t *lock)
{
    spin_lock(lock->spinlock);
}

static inline void wrunlock(rwlock_t *lock)
{
    spin_unlock(lock->spinlock);
}


很OK,不是吗?但是最好的方案就是彻底抛弃锁,彻底不用锁。
       我曾经在设计我的转发表的时候,为了降低lock开销,我为每个CPU复制了一个局部的本地转发表,这些转发表是一致的,由路由表生成,心想这就可以避免 竞争,然而,这些转发表总要面临更新问题,如何更新它们??我最初采用的方式是采用IPI(处理器间中断),在处理函数中,停掉处理线程,然后更新数据, 最后开启线程,这样可以在处理期间避免lock。十分合理,不是吗?可是我想复杂了。
       仔细看看读写锁的写锁,它鲁莽地进行了标准锁定操作,而读锁也是在第一个读者进来的时候采用了锁定动作。这些锁定操作导致的等待可以避免吗?看看我原始的 IPI方案,停掉线程是为了防止读者读到错误的数据,实际上是将主动将执行流让位给了写者,写者先来,然后再看看读写锁中的写者,发现有读者存在时,没有 主动地让位,而只是被动地等待,这种等待很无聊!
       能否将我的方式和读写锁的方式结合呢?
       怎么结合?按照刚刚的思路,无非就是为写者是被动等待还是抢先读者做一个决策!但是它还有一个别的选择,那就是先按照自己的流程写数据,不是写原始数据, 而是写原始数据的一份拷贝(伟大的写时拷贝),然后将这件事挂在一个未竟事务链表上直接走人,等待系统发现所有的读者都完成时用链表上的数据逐个覆盖原始 数据。这是个多么好的结合,这就是伟大的RCU锁。读者的代价就是简单地标示一下有人读即可,而写者也无需等待持锁,直接写副本,写完走人,后来的事就交 给系统了....

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-85946-1-1.html 上篇帖子: OpenSSL发布最新安全补丁解决高危漏洞 下篇帖子: linux下常用的查找文件命令 Linux
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表