宏定义: #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) 分解: typeof(x):取x的类型,如果x是int,那typeof(x)就是int volatile:禁止优化,从内存取值 ACCESS_ONCE:将x从内存取值,防止因为cache存在导致的不一致…

如果你看过 Linux 内核中的 RCU 的实现,你应该注意到了这个叫做 ACCESS_ONCE() 宏. ACCESS_ONCE的定义如下: #define __ACCESS_ONCE(x) ({ \ __maybe_unused ; \ (volatile typeof(x) *)&(x); }) #define ACCESS_ONCE(x) (*__ACCESS_ONCE(x)) 仅从语法上讲,这似乎毫无意义,先取其地址,在通过指针取其值.而实际上不然,多了一个关键词 volatile,所…

参考资料: https://blog.csdn.net/ganggexiongqi/article/details/24603363 这个真特么玄学了...…

基数树是一种用空间换时间的数据结构,通过空间的冗余减少时间上的消耗.radix tree很适合稀疏的结构! 自从把RCU机制引入到基树中来,这里就有了个协议叫做:lockless的page-cache协议! 一个小小的find_get_entry函数,里面处理了两种异常的情况,一是文件系统的page被free或者将要被free掉的情况,二是文件系统的page被remove掉的情况!第三种异常是slot中直接被标记无效的情况,还有就是slot中没有对应的page*的情况!但是这个槽为什么能搜到?是…

RCU(Read-Copy Update)是数据同步的一种方式,在当前的Linux内核中发挥着重要的作用.RCU主要针对的数据对象是链表,目的是提高遍历读取数据的效率,为了达到目的使用RCU机制读取数据的时候不对链表进行耗时的加锁操作.这样在同一时间可以有多个线程同时读取该链表,并且允许一个线程对链表进行修改(修改的时候,需要加锁).RCU适用于需要频繁的读取数据,而相应修改数据并不多的情景,例如在文件系统中,经常需要查找定位目录,而对目录的修改相对来说并不多,这就是RCU发挥作用的最佳场景.L…

Linux内核同步机制之(一):原子操作 http://www.wowotech.net/linux_kenrel/atomic.html 一.源由 我们的程序逻辑经常遇到这样的操作序列: 1.读一个位于memory中的变量的值到寄存器中 2.修改该变量的值(也就是修改寄存器中的值) 3.将寄存器中的数值写回memory中的变量值 如果这个操作序列是串行化的操作(在一个thread中串行执行),那么一切OK,然而,世界总是不能如你所愿.在多CPU体系结构中,运行在两个CPU上的两个内核控制路径同…

本文例子均在 Linux(g++)下验证通过,CPU 为 X86-64 处理器架构.所有罗列的 Linux 内核代码也均在(或只在)X86-64 下有效. 本文首先通过范例(以及内核代码)来解释 Memory barrier,然后介绍一个利用 Memory barrier 实现的无锁环形缓冲区. Memory barrier 简介 程序在运行时内存实际的访问顺序和程序代码编写的访问顺序不一定一致,这就是内存乱序访问.内存乱序访问行为出现的理由是为了提升程序运行时的性能.内存乱序访问主要发生在两个…

本文转载自:http://name5566.com/4535.html 参考文献列表:http://en.wikipedia.org/wiki/Memory_barrierhttp://en.wikipedia.org/wiki/Out-of-order_executionhttps://www.kernel.org/doc/Documentation/memory-barriers.txt 本文例子均在 Linux(g++)下验证通过,CPU 为 X86-64 处理器架构.所有罗列的 Linu…

理解 Memory barrier(内存屏障) 发布于 2014 年 04 月 21 日2014 年 05 月 15 日 作者 name5566 参考文献列表:http://en.wikipedia.org/wiki/Memory_barrierhttp://en.wikipedia.org/wiki/Out-of-order_executionhttps://www.kernel.org/doc/Documentation/memory-barriers.txt 本文例子均在 Linux(g+…

原文网址:http://blog.chinaunix.net/uid-23769728-id-3173282.html 这篇博文很长,虽然这是下篇,但还没结束,benchmark方面的东西正在进行中,另外还有一些问题我自己也在和别人讨论...所以我想除了还有“结束语”篇(其实这篇我基本写完了,但是还没最终盖棺论定,有些问题尚需要进一步讨论)之外,还应该会有个“实际性能测试”篇...理想是美好的,但是现实时间总是不够用滴.因此,我想说,如果这篇博文最后烂尾了,请网友们--把我埋在,埋在春天里...…