Linux内核6. 内核同步

内核6. 内核同步"/>

Linux内核6. 内核同步

同步

既然是同步机制，那就首先要搞明白什么是同步。同步是指用于实现控制多个执行路径按照一定的规则或顺序访问某些系统资源的机制。所谓执行路径，就是在 CPU 上运行的代码流。我们知道，CPU 调度的最小单位是线程，可以是用户态线程，也可以是内核线程，甚至是中断服务程序。所以，执行路径在这里就包括用户态线程、内核线程和中断服务程序。执行路径、执行单元、控制路径等等，叫法不同，但本质都一样。 

并发

内核中有多种可能造成并发执行的原因：

中断，几乎可以在任何时刻异步发生
软中断和tasklet，内核能在任何时刻唤醒或调度软中断和tasklet
内核抢占，一个任务可能会被另一个任务抢占
睡眠和用户空间同步，睡眠导致另一个进程开始执行
对称多处理，两个或多个处理器可以同时执行代码

中断与抢占

中断本身的概念很简单，本文不予解释。

抢占属于进程调度的概念，Linux 内核从 2.6 版本开始支持抢占调度。进程调度（管理）是 Linux 内核最核心的子系统之一，异常庞大，本文只简单介绍基本概念，对于同步机制的代码分析已然足够。通俗地说，抢占是指一个正愉快地运行在 CPU 上的 task（可以是用户态进程，也可以是内核线程） 被另一个 task（通常是更高优先级）夺去 CPU 执行权的故事。中断和抢占之间有着比较暧昧的关系，简单来说，抢占依赖中断。如果当前 CPU 禁止了本地中断，那么也意味着禁止了本 CPU 上的抢占。但反过来，禁掉抢占并不影响中断。Linux 内核中用 preempt_enable() 宏函数来开启本 CPU 的抢占，用 preempt_disable() 来禁掉本 CPU 的抢占。这里，“本 CPU” 这个描述其实不太准确，更严谨的说法是运行在当前 CPU 上的 task。preempt_enable() 和 preempt_disable() 的具体实现展开来介绍的话也可以单独成文了，笔者没有深究过，就不班门弄斧了，感兴趣的读者可以去 RTFSC。不管是用户态抢占还是内核态抢占，并不是什么代码位置都能发生，而是有抢占时机的，也就是所谓的抢占点。

抢占时机如下：

• 用户态抢占：1、从系统调用返回用户空间时；2、从中断（异常）处理程序返回用户空间时。
• 内核态抢占：1、当一个中断处理程序退出，返回到内核态时；2、task 显式调用 schedule()；3、task 发生阻塞（此时由调度器完成调度）。

二.  Linux 内核同步机制

常用的 Linux 内核同步机制有原子操作、Per-CPU 变量、内存屏障、自旋锁、Mutex 锁、信号量和 RCU 等，后面几种锁实现会依赖于前三种基础同步机制。

• 原子操作
• 信号量（semaphore）
• 读写信号量（rw_semaphore）
• Spinlock
• Mutex
• BKL(Big Kernel Lock，只包含在2.4内核中，不讲)
• Rwlock
• brlock（只包含在2.4内核中，不讲）
• RCU（只包含在2.6内核及以后的版本中）
• seqlock（只包含在2.6内核及以后的版本中）

三. 原子操作

所谓原子操作，就是该操作绝不会在执行完毕前被任何其他任务或事件打断，也就说，它的最小的执行单位，不可能有比它更小的执行单位，因此这里的原子实际是使用了物理学里的物质微粒的概念。

原子操作需要硬件的支持，因此是架构相关的，其API和原子类型的定义都定义在内核源码树的include/asm/atomic.h文件中，它们都使用汇编语言实现，因为C语言并不能实现这样的操作。

原子操作主要用于实现资源计数，很多引用计数(refcnt)就是通过原子操作实现的。原子类型定义如下：

typedef struct { 
volatile int counter; 
} atomic_t;

volatile修饰字段告诉gcc不要对该类型的数据做优化处理，对它的访问都是对内存的访问，而不是对寄存器的访问。

原子操作API包括：

• tomic_read(atomic_t * v);该函数对原子类型的变量进行原子读操作，它返回原子类型的变量v的值。
• atomic_set(atomic_t * v, int i);该函数设置原子类型的变量v的值为i。
• void atomic_add(int i, atomic_t *v);该函数给原子类型的变量v增加值i。
• atomic_sub(int i, atomic_t *v);该函数从原子类型的变量v中减去i。
• int atomic_sub_and_test(int i, atomic_t *v);该函数从原子类型的变量v中减去i，并判断结果是否为0，如果为0，返回真，否则返回假。
• void atomic_inc(atomic_t *v);该函数对原子类型变量v原子地增加1。
• void atomic_dec(atomic_t *v);该函数对原子类型的变量v原子地减1。
• int atomic_dec_and_test(atomic_t *v);该函数对原子类型的变量v原子地减1，并判断结果是否为0，如果为0，返回真，否则返回假。
• int atomic_inc_and_test(atomic_t *v);该函数对原子类型的变量v原子地增加1，并判断结果是否为0，如果为0，返回真，否则返回假。
• int atomic_add_negative(int i, atomic_t *v);该函数对原子类型的变量v原子地增加I，并判断结果是否为负数，如果是，返回真，否则返回假。
• int atomic_add_return(int i, atomic_t *v);该函数对原子类型的变量v原子地增加i，并且返回指向v的指针。
• int atomic_sub_return(int i, atomic_t *v);该函数从原子类型的变量v中减去i，并且返回指向v的指针。
• int atomic_inc_return(atomic_t * v);该函数对原子类型的变量v原子地增加1并且返回指向v的指针。
• int atomic_dec_return(atomic_t * v);该函数对原子类型的变量v原子地减1并且返回指向v的指针。

原子操作通常用于实现资源的引用计数，在TCP/IP协议栈的IP碎片处理中，就使用了引用计数，碎片队列结构struct ipq描述了一个IP碎片，字段refcnt就是引用计数器，它的类型为atomic_t，当创建IP碎片时（在函数ip_frag_create中），使用atomic_set函数把它设置为1，当引用该IP碎片时，就使用函数atomic_inc把引用计数加1。

当不需要引用该IP碎片时，就使用函数ipq_put来释放该IP碎片，ipq_put使用函数atomic_dec_and_test把引用计数减1并判断引用计数是否为0，如果是就释放IP碎片。函数ipq_kill把IP碎片从ipq队列中删除，并把该删除的IP碎片的引用计数减1（通过使用函数atomic_dec实现）。

四、信号量（semaphore）

Linux内核的信号量在概念和原理上与用户态的System V的IPC机制信号量是一样的，但是它绝不可能在内核之外使用，因此它与System V的IPC机制信号量毫不相干。

信号量在创建时需要设置一个初始值，表示同时可以有几个任务可以访问该信号量保护的共享资源，初始值为1就变成互斥锁（Mutex），即同时只能有一个任务可以访问信号量保护的共享资源。

一个任务要想访问共享资源，首先必须得到信号量，获取信号量的操作将把信号量的值减1，若当前信号量的值为负数，表明无法获得信号量，该任务必须挂起在该信号量的等待队列等待该信号量可用；若当前信号量的值为非负数，表示可以获得信号量，因而可以立刻访问被该信号量保护的共享资源。

当任务访问完被信号量保护的共享资源后，必须释放信号量，释放信号量通过把信号量的值加1实现，如果信号量的值为非正数，表明有任务等待当前信号量，因此它也唤醒所有等待该信号量的任务。

信号量的API有：

• DECLARE_MUTEX(name)该宏声明一个信号量name并初始化它的值为0，即声明一个互斥锁。
• DECLARE_MUTEX_LOCKED(name)该宏声明一个互斥锁name，但把它的初始值设置为0，即锁在创建时就处在已锁状态。因此对于这种锁，一般是先释放后获得。
• void sema_init (struct semaphore *sem, int val);该函用于数初始化设置信号量的初值，它设置信号量sem的值为val。
• void init_MUTEX (struct semaphore *sem);该函数用于初始化一个互斥锁，即它把信号量sem的值设置为1。
• void init_MUTEX_LOCKED (struct semaphore *sem);该函数也用于初始化一个互斥锁，但它把信号量sem的值设置为0，即一开始就处在已锁状态。
• void down(struct semaphore * sem);该函数用于获得信号量sem，它会导致睡眠，因此不能在中断上下文（包括IRQ上下文和softirq上下文）使用该函数。该函数将把sem的值减1，如果信号量sem的值非负，就直接返回，否则调用者将被挂起，直到别的任务释放该信号量才能继续运行。
• int down_interruptible(struct semaphore * sem);该函数功能与down类似，不同之处为，down不会被信号（signal）打断，但down_interruptible能被信号打断，因此该函数有返回值来区分是正常返回还是被信号中断，如果返回0，表示获得信号量正常返回，如果被信号打断，返回-EINTR。
• int down_trylock(struct semaphore * sem);该函数试着获得信号量sem，如果能够立刻获得，它就获得该信号量并返回0，否则，表示不能获得信号量sem，返回值为非0值。因此，它不会导致调用者睡眠，可以在中断上下文使用。
• void up(struct semaphore * sem);该函数释放信号量sem，即把sem的值加1，如果sem的值为非正数，表明有任务等待该信号量，因此唤醒这些等待者。

信号量在绝大部分情况下作为互斥锁使用，下面以console驱动系统为例说明信号量的使用。

在内核源码树的kernel/printk.c中，使用宏DECLARE_MUTEX声明了一个互斥锁console_sem，它用于保护console驱动列表console_drivers以及同步对整个console驱动系统的访问。

其中定义了函数acquire_console_sem来获得互斥锁console_sem，定义了release_console_sem来释放互斥锁console_sem，定义了函数try_acquire_console_sem来尽力得到互斥锁console_sem。这三个函数实际上是分别对函数down，up和down_trylock的简单包装。

需要访问console_drivers驱动列表时就需要使用acquire_console_sem来保护console_drivers列表，当访问完该列表后，就调用release_console_sem释放信号量console_sem。

函数console_unblank，console_device，console_stop，console_start，register_console和unregister_console都需要访问console_drivers，因此它们都使用函数对acquire_console_sem和release_console_sem来对console_drivers进行保护。

五、读写信号量（rw_semaphore）

写信号量对访问者进行了细分，或者为读者，或者为写者，读者在保持读写信号量期间只能对该读写信号量保护的共享资源进行读访问，如果一个任务除了需要读，可能还需要写，那么它必须被归类为写者，它在对共享资源访问之前必须先获得写者身份，写者在发现自己不需要写访问的情况下可以降级为读者。读写信号量同时拥有的读者数不受限制，也就说可以有任意多个读者同时拥有一个读写信号量。

如果一个读写信号量当前没有被写者拥有并且也没有写者等待读者释放信号量，那么任何读者都可以成功获得该读写信号量；否则，读者必须被挂起直到写者释放该信号量。如果一个读写信号量当前没有被读者或写者拥有并且也没有写者等待该信号量，那么一个写者可以成功获得该读写信号量，否则写者将被挂起，直到没有任何访问者。因此，写者是排他性的，独占性的。

读写信号量有两种实现，一种是通用的，不依赖于硬件架构，因此，增加新的架构不需要重新实现它，但缺点是性能低，获得和释放读写信号量的开销大；另一种是架构相关的，因此性能高，获取和释放读写信号量的开销小，但增加新的架构需要重新实现。在内核配置时，可以通过选项去控制使用哪一种实现。

读写信号量的相关API有：

• DECLARE_RWSEM(name)该宏声明一个读写信号量name并对其进行初始化。
• void init_rwsem(struct rw_semaphore *sem);该函数对读写信号量sem进行初始化。
• void down_read(struct rw_semaphore *sem);读者调用该函数来得到读写信号量sem。该函数会导致调用者睡眠，因此只能在进程上下文使用。
• int down_read_trylock(struct rw_semaphore *sem);该函数类似于down_read，只是它不会导致调用者睡眠。它尽力得到读写信号量sem，如果能够立即得到，它就得到该读写信号量，并且返回1，否则表示不能立刻得到该信号量，返回0。因此，它也可以在中断上下文使用。
• void down_write(struct rw_semaphore *sem);写者使用该函数来得到读写信号量sem，它也会导致调用者睡眠，因此只能在进程上下文使用。
• int down_write_trylock(struct rw_semaphore *sem);该函数类似于down_write，只是它不会导致调用者睡眠。该函数尽力得到读写信号量，如果能够立刻获得，就获得该读写信号量并且返回1，否则表示无法立刻获得，返回0。它可以在中断上下文使用。
• void up_read(struct rw_semaphore *sem);读者使用该函数释放读写信号量sem。它与down_read或down_read_trylock配对使用。如果down_read_trylock返回0，不需要调用up_read来释放读写信号量，因为根本就没有获得信号量。
• void up_write(struct rw_semaphore *sem);写者调用该函数释放信号量sem。它与down_write或down_write_trylock配对使用。如果down_write_trylock返回0，不需要调用up_write，因为返回0表示没有获得该读写信号量。
• void downgrade_write(struct rw_semaphore *sem);该函数用于把写者降级为读者，这有时是必要的。因为写者是排他性的，因此在写者保持读写信号量期间，任何读者或写者都将无法访问该读写信号量保护的共享资源，对于那些当前条件下不需要写访问的写者，降级为读者将，使得等待访问的读者能够立刻访问，从而增加了并发性，提高了效率。对于那些当前条件下不需要写访问的写者，降级为读者将，使得等待访问的读者能够立刻访问，从而增加了并发性，提高了效率。读写信号量适于在读多写少的情况下使用，在linux内核中对进程的内存映像描述结构的访问就使用了读写信号量进行保护。

在Linux中，每一个进程都用一个类型为task_t或struct task_struct的结构来描述，该结构的类型为struct mm_struct的字段mm描述了进程的内存映像，特别是mm_struct结构的mmap字段维护了整个进程的内存块列表，该列表将在进程生存期间被大量地遍利或修改。结构的mmap字段维护了整个进程的内存块列表，该列表将在进程生存期间被大量地遍利或修改。

因此mm_struct结构就有一个字段mmap_sem来对mmap的访问进行保护，mmap_sem就是一个读写信号量，在proc文件系统里有很多进程内存使用情况的接口，通过它们能够查看某一进程的内存使用情况，命令free、ps和top都是通过proc来得到内存使用信息的，proc接口就使用down_read和up_read来读取进程的mmap信息。

当进程动态地分配或释放内存时，需要修改mmap来反映分配或释放后的内存映像，因此动态内存分配或释放操作需要以写者身份获得读写信号量mmap_sem来对mmap进行更新。系统调用brk和munmap就使用了down_write和up_write来保护对mmap的访问。

六、自旋锁（spinlock）

自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。

由于自旋锁使用者一般保持锁时间非常短，因此选择自旋而不是睡眠是非常必要的，自旋锁的效率远高于互斥锁。

信号量和读写信号量适合于保持时间较长的情况，它们会导致调用者睡眠，因此只能在进程上下文使用（_trylock的变种能够在中断上下文使用），而自旋锁适合于保持时间非常短的情况，它可以在任何上下文使用。

如果被保护的共享资源只在进程上下文访问，使用信号量保护该共享资源非常合适，如果对共巷资源的访问时间非常短，自旋锁也可以。但是如果被保护的共享资源需要在中断上下文访问（包括底半部即中断处理句柄和顶半部即软中断），就必须使用自旋锁。

自旋锁保持期间是抢占失效的，而信号量和读写信号量保持期间是可以被抢占的。自旋锁只有在内核可抢占或SMP的情况下才真正需要，在单CPU且不可抢占的内核下，自旋锁的所有操作都是空操作。

跟互斥锁一样，一个执行单元要想访问被自旋锁保护的共享资源，必须先得到锁，在访问完共享资源后，必须释放锁。如果在获取自旋锁时，没有任何执行单元保持该锁，那么将立即得到锁；如果在获取自旋锁时锁已经有保持者，那么获取锁操作将自旋在那里，直到该自旋锁的保持者释放了锁。

无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。

自旋锁的API有：

• spin_lock_init(x)该宏用于初始化自旋锁x。自旋锁在真正使用前必须先初始化。该宏用于动态初始化。
• DEFINE_SPINLOCK(x)该宏声明一个自旋锁x并初始化它。该宏在2.6.11中第一次被定义，在先前的内核中并没有该宏。
• SPIN_LOCK_UNLOCKED该宏用于静态初始化一个自旋锁。
• DEFINE_SPINLOCK(x)等同于spinlock_t x = SPIN_LOCK_UNLOCKEDspin_is_locked(x)该宏用于判断自旋锁x是否已经被某执行单元保持（即被锁），如果是，返回真，否则返回假。
• spin_unlock_wait(x)该宏用于等待自旋锁x变得没有被任何执行单元保持，如果没有任何执行单元保持该自旋锁，该宏立即返回，否则将循环在那里，直到该自旋锁被保持者释放。
• spin_trylock(lock)该宏尽力获得自旋锁lock，如果能立即获得锁，它获得锁并返回真，否则不能立即获得锁，立即返回假。它不会自旋等待lock被释放。
• spin_lock(lock)该宏用于获得自旋锁lock，如果能够立即获得锁，它就马上返回，否则，它将自旋在那里，直到该自旋锁的保持者释放，这时，它获得锁并返回。总之，只有它获得锁才返回。
• spin_lock_irqsave(lock, flags)该宏获得自旋锁的同时把标志寄存器的值保存到变量flags中并失效本地中断。
• spin_lock_irq(lock)该宏类似于spin_lock_irqsave，只是该宏不保存标志寄存器的值。
• spin_lock_bh(lock)该宏在得到自旋锁的同时失效本地软中断。
• spin_unlock(lock)该宏释放自旋锁lock，它与spin_trylock或spin_lock配对使用。如果spin_trylock返回假，表明没有获得自旋锁，因此不必使用spin_unlock释放。
• spin_unlock_irqrestore(lock, flags)该宏释放自旋锁lock的同时，也恢复标志寄存器的值为变量flags保存的值。它与spin_lock_irqsave配对使用。
• spin_unlock_irq(lock)该宏释放自旋锁lock的同时，也使能本地中断。它与spin_lock_irq配对应用。
• spin_unlock(lock)该宏释放自旋锁lock，它与spin_trylock或spin_lock配对使用。如果spin_trylock返回假，表明没有获得自旋锁，因此不必使用spin_unlock释放。
• spin_unlock_irqrestore(lock, flags)该宏释放自旋锁lock的同时，也恢复标志寄存器的值为变量flags保存的值。它与spin_lock_irqsave配对使用。
• spin_unlock_irq(lock)该宏释放自旋锁lock的同时，也使能本地中断。它与spin_lock_irq配对应用。
• spin_unlock_bh(lock)该宏释放自旋锁lock的同时，也使能本地的软中断。它与spin_lock_bh配对使用。
• spin_trylock_irqsave(lock, flags) 该宏如果获得自旋锁lock，它也将保存标志寄存器的值到变量flags中，并且失效本地中断，如果没有获得锁，它什么也不做。因此如果能够立即获得锁，它等同于spin_lock_irqsave，如果不能获得锁，它等同于spin_trylock。如果该宏获得自旋锁lock，那需要使用spin_unlock_irqrestore来释放。
• spin_unlock_bh(lock)该宏释放自旋锁lock的同时，也使能本地的软中断。它与spin_lock_bh配对使用。
• spin_trylock_irqsave(lock, flags) 该宏如果获得自旋锁lock，它也将保存标志寄存器的值到变量flags中，并且失效本地中断，如果没有获得锁，它什么也不做。因此如果能够立即获得锁，它等同于spin_lock_irqsave，如果不能获得锁，它等同于spin_trylock。如果该宏获得自旋锁lock，那需要使用spin_unlock_irqrestore来释放。
• spin_can_lock(lock)该宏用于判断自旋锁lock是否能够被锁，它实际是spin_is_locked取反。如果lock没有被锁，它返回真，否则，返回假。该宏在2.6.11中第一次被定义，在先前的内核中并没有该宏。

自旋锁和释放自旋锁 几个版本

获得自旋锁和释放自旋锁有好几个版本，因此让读者知道在什么样的情况下使用什么版本的获得和释放锁的宏是非常必要的。

如果被保护的共享资源只在进程上下文访问和软中断上下文访问，那么当在进程上下文访问共享资源时，可能被软中断打断，从而可能进入软中断上下文来对被保护的共享资源访问，因此对于这种情况，对共享资源的访问必须使用spin_lock_bh和spin_unlock_bh来保护。

当然使用spin_lock_irq和spin_unlock_irq以及spin_lock_irqsave和spin_unlock_irqrestore也可以，它们失效了本地硬中断，失效硬中断隐式地也失效了软中断。但是使用spin_lock_bh和spin_unlock_bh是最恰当的，它比其他两个快。

如果被保护的共享资源只在进程上下文和tasklet或timer上下文访问，那么应该使用与上面情况相同的获得和释放锁的宏，因为tasklet和timer是用软中断实现的。

如果被保护的共享资源只在一个tasklet或timer上下文访问，那么不需要任何自旋锁保护，因为同一个tasklet或timer只能在一个CPU上运行，即使是在SMP环境下也是如此。实际上tasklet在调用tasklet_schedule标记其需要被调度时已经把该tasklet绑定到当前CPU，因此同一个tasklet决不可能同时在其他CPU上运行。

timer也是在其被使用add_timer添加到timer队列中时已经被帮定到当前CPU，所以同一个timer绝不可能运行在其他CPU上。当然同一个tasklet有两个实例同时运行在同一个CPU就更不可能了。

如果被保护的共享资源只在两个或多个tasklet或timer上下文访问，那么对共享资源的访问仅需要用spin_lock和spin_unlock来保护，不必使用_bh版本，因为当tasklet或timer运行时，不可能有其他tasklet或timer在当前CPU上运行。

如果被保护的共享资源只在一个软中断（tasklet和timer除外）上下文访问，那么这个共享资源需要用spin_lock和spin_unlock来保护，因为同样的软中断可以同时在不同的CPU上运行。

如果被保护的共享资源在两个或多个软中断上下文访问，那么这个共享资源当然更需要用spin_lock和spin_unlock来保护，不同的软中断能够同时在不同的CPU上运行。

如果被保护的共享资源在软中断（包括tasklet和timer）或进程上下文和硬中断上下文访问，那么在软中断或进程上下文访问期间，可能被硬中断打断，从而进入硬中断上下文对共享资源进行访问，因此，在进程或软中断上下文需要使用spin_lock_irq和spin_unlock_irq来保护对共享资源的访问。

而在中断处理句柄中使用什么版本，需依情况而定，如果只有一个中断处理句柄访问该共享资源，那么在中断处理句柄中仅需要spin_lock和spin_unlock来保护对共享资源的访问就可以了。

因为在执行中断处理句柄期间，不可能被同一CPU上的软中断或进程打断。但是如果有不同的中断处理句柄访问该共享资源，那么需要在中断处理句柄中使用spin_lock_irq和spin_unlock_irq来保护对共享资源的访问。

在使用spin_lock_irq和spin_unlock_irq的情况下，完全可以用spin_lock_irqsave和spin_unlock_irqrestore取代，那具体应该使用哪一个也需要依情况而定，如果可以确信在对共享资源访问前中断是使能的，那么使用spin_lock_irq更好一些。

因为它比spin_lock_irqsave要快一些，但是如果你不能确定是否中断使能，那么使用spin_lock_irqsave和spin_unlock_irqrestore更好，因为它将恢复访问共享资源前的中断标志而不是直接使能中断。

当然，有些情况下需要在访问共享资源时必须中断失效，而访问完后必须中断使能，这样的情形使用spin_lock_irq和spin_unlock_irq最好。

需要特别提醒读者，spin_lock用于阻止在不同CPU上的执行单元对共享资源的同时访问以及不同进程上下文互相抢占导致的对共享资源的非同步访问，而中断失效和软中断失效却是为了阻止在同一CPU上软中断或中断对共享资源的非同步访问。

读写锁

自旋锁不关心锁定的临界区究竟在进行什么操作，不管是读还是写，它都一视同仁。即便多个执行单元同时读取临界资源也会被锁住。实际上，对共享资源并发访问时，多个执行单元同时读取它是不会有问题的，自旋锁的衍生锁读写自旋锁（rwlock）可允许读的并发。读写自旋锁是一种比自旋锁粒度更小的锁机制，它保留了“自旋”的概念，但是在写操作方面，只能最多有1个写进程，在读操作方面，同时可以有多个读执行单元。当然，读和写也不能同时进行。

定义和初始化读写自旋锁：

rwlock_t my_rwlock;

rwlock_init(&my_rwlock);

读锁定:

void read_lock(rwlock_t *lock);

void read_lock_irqsave(rwlock_t *lock, unsigned long flags);

void read_lock_irq(rwlock_t *lock);

void read_lock_bh(rwlock_t *lock);

读解锁:

void read_unlock(rwlock_t *lock);

void read_unlock_irqrestore(rwlock_t *lock, unsigned long flags);

void read_unlock_irq(rwlock_t *lock);

void read_unlock_bh(rwlock_t *lock);

在对共享资源进行读取之前，应该先调用读锁定函数，完成之后应调用读解锁函数。 read_lock_irqsave（）、read_lock_irq（）和read_lock_bh（）也分别是read_lock（）分别与 local_irq_save（）、local_irq_disable（）和local_bh_disable（）的组合，读解锁函数 read_unlock_irqrestore（）、read_unlock_irq（）、read_unlock_bh（）的情况与此类似。

写锁定:

void write_lock(rwlock_t *lock);

void write_lock_irqsave(rwlock_t *lock, unsigned long flags);

void write_lock_irq(rwlock_t *lock);

void write_lock_bh(rwlock_t *lock);

int write_trylock(rwlock_t *lock);

写解锁:

void write_unlock(rwlock_t *lock);

void write_unlock_irqrestore(rwlock_t *lock, unsigned long flags);

void write_unlock_irq(rwlock_t *lock);

void write_unlock_bh(rwlock_t *lock);

write_lock_irqsave（）、write_lock_irq（）、write_lock_bh（）分别是write_lock（）与 local_irq_save（）、local_irq_disable（）和local_bh_disable（）的组合，写解锁函数 write_unlock_irqrestore（）、write_unlock_irq（）、write_unlock_bh（）的情况与此类似。 在对共享资源进行写之前，应该先调用写锁定函数，完成之后应调用写解锁函数。和spin_trylock（）一样，write_trylock（）也只是尝试获取读写自旋锁，不管成功失败，都会立即返回。

读写自旋锁一般这样被使用:

七. 互斥锁（Mutex）

Linux 内核互斥锁是非常常用的同步机制，互斥锁是这样一种同步机制：在互斥锁中同时只能有一个任务可以访问该锁保护的共享资源，且释放锁和获得锁的调用方必须一致。因此在互斥锁中，除了对锁本身进行同步，对调用方（或称持有者）必须也进行同步。当互斥锁无法获得时，task会加入等待队列，直至可获得锁为止。

Structure Definition

互斥锁从结构上看与信号量十分类似，但将原本的int类型的count计数，改成了atomic_long_t的owner以便同步，保证释放者与持有者一致。

mutex_lock & mutex_unlock

上图简单的表现了mutex_lock与mutex_unlock实现的对称性，___mutex_trylock_fast用于owner为0的特殊状态，用于快速加锁，实现核心在slowpath版本上。

*might_sleep指在之后的代码执行中可能会sleep。

由于mutex实现的具体步骤相当复杂，这里选讲比较核心简单的两块。Mutex有关等待队列的处理比较复杂，有兴趣阅读相关内核书籍。

当且仅当lock当前的owner没有变化时（没有其他mutex抢先拥有该锁），此时获得锁，返回NULL, owner 为 curr | flags,owner本身对应task指针。若该锁已被占用，owner和当前task不匹配，返回owner对应指针。

当unlock时，不考虑等待队列的影响，则与上述类似，当且仅当之前持有锁的owner可以解锁，解锁时本来应将lock的owner置为初始0，但是这里保留了mutex的flag以便后续操作。

*这里的owner实际上是task_struct的指针，也就是地址，由于task_struct的地址是L1_cache对齐的，因此实际上指针地址后三位为0，因此linux内核利用这三个比特位用于设置mutex的标志位，不影响指针地址的表示也更高效利用了冗余的比特位。

Mutex 的改进

最初的互斥锁仅支持睡眠等待，然而经过漫长时间的改进，如今的互斥锁已经可以支持自旋等待，通过MCS锁机制实现。在内核中可以选择配置以支持，
CONFIG_MUTEX_SPIN_ON_OWNER。

如上是4.9内核中mutex中常用有效的字段，目前最常用的算法是OSQ算法。自旋等待机制的核心原理是当发现持有者正在临界区执行并且没有其他优先级高的进程要被调度（need_resched）时，那么mutex当前所在进程认为该持有者很快会离开临界区并释放锁，此时mutex选择自旋等待，短时间的自旋等待显然比睡眠-唤醒开销小一些。

在实现上MCS保证了同一时间只有一个进程自旋等待持有者释放锁。MCS 的实现较为复杂，具体可参考一些内核书籍。MCS保证了不会存在多个cpu争用锁的情况，从而避免了多个CPU的cacheline颠簸从而降低系统性能的问题。

经过改进后，mutex的性能有了相当大的提高，相对信号量的实现要高效得多。因此我们尽量选用mutex。

Mutex 的使用条件

Mutex虽然高效，灵活，但存在若干限制条件，需要牢记:

• 同一时刻只有一条内核路径可以持有锁
• 只有锁持有者可以解锁
• 不允许递归加锁解锁
• 进程持有mutex时不可退出
• Mutex 可能导致睡眠阻塞，不可用于中断处理与下半部使用

Mutex API

大内核锁BLK
略

顺序锁

顺序锁，通常称为seq锁。这种锁提供了一种简单的机制，用于读写共享数据。其原理是依靠一个序列计数器，当需要写入数据，会得到一个锁，并增加序列值；在读取数据前后，序列值都会被读取，如果读取的序列值相同，则说明读操作过程中没有新的数据写入。
注意：如果读取的值是偶数，则表明写操作没有发生或已经完成，因为序列值初始为偶数0，加写锁时会让序列值加1变为奇数，而释放的时候又会变成偶数。

和读写锁不同之处在于，顺序锁对写操作加锁更加友好，只有没有其他写者，写锁总是能够获取的。

关闭内核抢占

不同进程可能会访问同一个临界区，因此对于单处理器来说，在访问临界区期间不允许内核抢占也是一种同步方法。

顺序和屏障

当处理多处理器之间或硬件设备之间的同步问题时，有时需要在程序中以指定的顺序发出读内存和写内存的指令（指令的指令要按照特定的顺序）。但是为了提高效率，编译器或处理器可能会对程序指令重新排序（例如，处理器在执行指令期间，会在取指令和分派时，把表面上看上去无关的指令按照自认为最好的方式排序）。值得庆幸的是，所有可能重新排序指令的处理器都提供了机器指令来确保顺序的要求。同样，也可以指示编译器不要对给定点周围的指令序列进行重新排序。这些确保顺序的指令称为屏障。

相关的指令有rmb、wmb、mb、read_barrier_depends等等；具体的细节可以百度查询下，这个东西是一个比较关键的东西。总的来说，它能够保证处理器能够按照我们在程序中指定的顺序去执行指令。

总结一些帮助理解的话
1.我们希望ISR是原子的，没有人能够抢占ISR。 因此，ISR禁用本地中断(即当前处理器上的中断)，并且一旦ISR调用ret_from_intr()函数(即我们已完成ISR)，则在当前处理器上再次启用中断。 如果此期间发生中断，它将由另一个处理器(在SMP系统中)提供服务，并且与该中断相关的ISR将开始运行。因此，在SMP系统中，我们还需要在ISR中包含适当的同步机制(自旋锁)。

2.注意中断上下文中无法睡眠，无法进行进程调度，一旦执行，就会一直执行下去，直到结束。

3.中断下半部也可以抢占进程上下文，同一个处理器下半部之间不会互相抢占，例如软中断，当一个软中断在执行时，当前处理器的软中断被禁止了。

4.如果内核具有抢占性，那么内核中的进程在任何时候都可能停下来以便具有更高优先权的进程运行。
————————————————
版权声明：本文为CSDN博主「抱猫人」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：