首页 文章 精选 留言 我的

精选列表

搜索[update],共8755篇文章
优秀的个人博客,低调大师

Linux内核RCU(Read Copy Update)锁简析-前传

如果你用Linux perf tool的top命令做热点纠察时,你会发现,前10名嫌疑犯里面肯定有好几个都是锁! 在进行并行多处理时,不可 避免地会遇到锁的问题,这是不可避免的,因为这一直以来也许是保护共享数据的唯一方式,被保护的区域就是临界区。而我们知道,锁的开销是巨大的,因为它不 可避免地要么等待,要么让别人等待,然而这并不是开销的本质,开销的本质在于很多锁都采用了“原子操作”这么一个技术,如此一个原子操作会对总线或者 cache一致性造成很大的影响,比如要对一个变量进行原子加1,不要认为它很简单,其实背后会有很多不希望的操作,在某架构的处理器上,首先要LOCK 总线,这意味着LOCK不解除期间,其它处理器不能访存(起码是内存的某些区域),可能还要涉及到刷cache,或者触发cache一致性操作...这还 不算最猛的打击,在某些架构上,存在内存栅栏,它会刷掉CPU的流水线,刷掉cache,几乎所有的为优化而设计的方案全部失效,当然,这是代价,收益就 是你保护了临界区。 你要保护临界区,你要付出代价,这个代价如果用复杂的锁来支付的话,未免有点大。非要这样子吗?也许是你的数据结构设计地不好,也许是你的代码流设计地不 好,比如多个线程同时读共享数据,两个线程一个读一个写,能否采用环形缓冲区来减轻竞争呢?事实上很多诸如网卡,硬盘等共享外设驱动程序都是这么玩的,代 码只要保证读指针和写指针不相互超越即可,这样可以最小化锁的使用,当然这只是一个非常简单的例子。 设计好的数据结构和代码流程是一方面,但是这个层次不够抽象,更好的方式就是设计一种更加优化的锁。读写锁这种不对称的锁应对读者多写者少的情景是一种优 化的锁,它对读者的优待就是无需等待,只要没有写者就可以直接读,否则才等待。而对于写者,它需要等待所有读者的完成。这种读写的实现可以依赖于另一种叫 做自旋锁的机制实现,我的一个实现如下所示: typedefstruct{ spinlock_t*spinlock; atomic_treaders; }rwlock_t; staticinlinevoidrdlock(rwlock_t*lock) { spinlock_t*lck=lock->spinlock; if(likely(!lock->readers++)) spin_lock(lck); } staticinlinevoidrdunlock(rwlock_t*lock) { spinlock_t*lck=lock->spinlock; if(likely(!--lock->readers)) spin_unlock(lck); } staticinlinevoidwrlock(rwlock_t*lock) { spin_lock(lock->spinlock); } staticinlinevoidwrunlock(rwlock_t*lock) { spin_unlock(lock->spinlock); } 很OK,不是吗?但是最好的方案就是彻底抛弃锁,彻底不用锁。 我曾经在设计我的转发表的时候,为了降低lock开销,我为每个CPU复制了一个局部的本地转发表,这些转发表是一致的,由路由表生成,心想这就可以避免 竞争,然而,这些转发表总要面临更新问题,如何更新它们??我最初采用的方式是采用IPI(处理器间中断),在处理函数中,停掉处理线程,然后更新数据, 最后开启线程,这样可以在处理期间避免lock。十分合理,不是吗?可是我想复杂了。 仔细看看读写锁的写锁,它鲁莽地进行了标准锁定操作,而读锁也是在第一个读者进来的时候采用了锁定动作。这些锁定操作导致的等待可以避免吗?看看我原始的 IPI方案,停掉线程是为了防止读者读到错误的数据,实际上是将主动将执行流让位给了写者,写者先来,然后再看看读写锁中的写者,发现有读者存在时,没有 主动地让位,而只是被动地等待,这种等待很无聊! 能否将我的方式和读写锁的方式结合呢? 怎么结合?按照刚刚的思路,无非就是为写者是被动等待还是抢先读者做一个决策!但是它还有一个别的选择,那就是先按照自己的流程写数据,不是写原始数据, 而是写原始数据的一份拷贝(伟大的写时拷贝),然后将这件事挂在一个未竟事务链表上直接走人,等待系统发现所有的读者都完成时用链表上的数据逐个覆盖原始 数据。这是个多么好的结合,这就是伟大的RCU锁。读者的代价就是简单地标示一下有人读即可,而写者也无需等待持锁,直接写副本,写完走人,后来的事就交 给系统了.... 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1673574

优秀的个人博客,低调大师

更新卡券接口(alipay.pass.instance.update)JAVA版本小样

官方接口文档:https://docs.open.alipay.com/199/105250/ 发放卡券接口参考该贴:https://openclub.alipay.com/read.php?tid=2193&fid=8 使用场景介绍 对于已经发布的卡券,商户可通过此接口进行更新,更新卡券接口包含三大主要功能:核销卡券、失效卡券、更新卡券样式内容 核销卡券功能 核销卡券主要描述开发者如何将发放出去的卡券进行核销,使卡券在用户的支付宝客户端展示为已使用状态。对于支付宝卡券而言,核销操作只是将卡券状态变更为USED(已使用),用户客户端展示为已使用状态,未涉及资金流的核销。仅支持核销有效状态的卡券,若卡券处于卡券删除或者已转赠,不可进行核销操作 失效卡券功能 失效卡券主要描述开发者如何将发放出去的卡券进行作废,让卡券在用户的支付

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册