本帖最后由 玩转Linux内核 于 2022-7-11 01:47 编辑
本帖最后由 玩转Linux内核 于 2022-7-11 01:46 编辑
在LInux操作系统里，同一时间可能有多个内核执行流在执行，因此内核其实象多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问。尤其是在多处理器系统上，更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。
上期回顾：一文搞懂Linux内核的同步机制（原子操作、信号量、读写量）
八，RCU(Read-Copy Update)
RCU简介
RCU(Read-Copy Update)，顾名思义就是读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。
因此RCU实际上是一种改进的rwlock，读者几乎没有什么同步开销，它不需要锁，不使用原子指令，而且在除alpha的所有架构上也不需要内存栅（Memory Barrier），因此不会导致锁竞争，内存延迟以及流水线停滞。不需要锁也使得使用更容易，因为死锁问题就不需要考虑了。写者的同步开销比较大，它需要延迟数据结构的释放，复制被修改的数据结构，它也必须使用某种锁机制同步并行的其它写者的修改操作。
读者必须提供一个信号给写者以便写者能够确定数据可以被安全地释放或修改的时机。有一个专门的垃圾收集器来探测读者的信号，一旦所有的读者都已经发送信号告知它们都不在使用被RCU保护的数据结构，垃圾收集器就调用回调函数完成最后的数据释放或修改操作。
RCU与rwlock的不同之处是：它既允许多个读者同时访问被保护的数据，又允许多个读者和多个写者同时访问被保护的数据（注意：是否可以有多个写者并行访问取决于写者之间使用的同步机制），读者没有任何同步开销，而写者的同步开销则取决于使用的写者间同步机制。但RCU不能替代rwlock，因为如果写比较多时，对读者的性能提高不能弥补写者导致的损失。
读者在访问被RCU保护的共享数据期间不能被阻塞，这是RCU机制得以实现的一个基本前提，也就说当读者在引用被RCU保护的共享数据期间，读者所在的CPU不能发生上下文切换，spinlock和rwlock都需要这样的前提。写者在访问被RCU保护的共享数据时不需要和读者竞争任何锁，只有在有多于一个写者的情况下需要获得某种锁以与其他写者同步。
写者修改数据前首先拷贝一个被修改元素的副本，然后在副本上进行修改，修改完毕后它向垃圾回收器注册一个回调函数以便在适当的时机执行真正的修改操作。等待适当时机的这一时期称为宽限期(grace period)，而CPU发生了上下文切换称为经历一个quiescent state，grace period就是所有CPU都经历一次quiescent state所需要的等待的时间。垃圾收集器就是在grace period之后调用写者注册的回调函数来完成真正的数据修改或数据释放操作的。
以下以链表元素删除为例详细说明这一过程。
写者要从链表中删除元素 B，它首先遍历该链表得到指向元素 B 的指针，然后修改元素 B 的前一个元素的 next 指针指向元素 B 的 next 指针指向的元素C，修改元素 B 的 next 指针指向的元素 C 的 prep 指针指向元素 B 的 prep指针指向的元素 A,在这期间可能有读者访问该链表，修改指针指向的操作是原子的，所以不需要同步，而元素 B 的指针并没有去修改，因为读者可能正在使用 B 元素来得到下一个或前一个元素。写者完成这些操作后注册一个回调函数以便在 grace period 之后删除元素 B，然后就认为已经完成删除操作。垃圾收集器在检测到所有的CPU不在引用该链表后，即所有的 CPU 已经经历了 quiescent state,grace period 已经过去后，就调用刚才写者注册的回调函数删除了元素 B。
使用 RCU 进行链表删除操作：
读者在读取由RCU保护的共享数据时使用该函数标记它进入读端临界区。
rcu_read_unlock()
该函数与rcu_read_lock配对使用，用以标记读者退出读端临界区。
夹在这两个函数之间的代码区称为”读端临界区”(read-side critical section)。读端临界区可以嵌套，如图3，临界区2被嵌套在临界区1内。
嵌套读端临界区示例：
那么在读端临界区发生了什么？要回答这个问题需要搞清楚rcu_read_lock和rcu_read_unlock做了什么操作，实际上即关闭内核抢占和打开内核抢占
static inline void __rcu_read_lock(void)
{
preempt_disable();
}
static inline void __rcu_read_unlock(void)
{preempt_enable();}
即在读端临界区中时内核是禁止抢占的。
那么这时是否度过宽限期(Grace Period)的判断就比较简单：每个CPU都经过一次抢占。因为发生抢占，就说明不在rcu_read_lock和rcu_read_unlock之间，必然已经完成访问或者还未开始访问。
synchronize_rcu()
该函数由RCU写端调用，它将阻塞写者，直到经过grace period后，即所有的读者已经完成读端临界区，写者才可以继续下一步操作。如果有多个RCU写端调用该函数，他们将在一个grace period之后全部被唤醒。
注意，该函数在2.6.11及以前的2.6内核版本中为synchronize_kernel，只是在2.6.12才更名为synchronize_rcu,但在2.6.12中也提供了synchronize_kernel和一个新的函数synchronize_sched，因为以前有很多内核开发者使用synchronize_kernel用于等待所有CPU都退出不可抢占区，而在RCU设计时该函数只是用于等待所有CPU都退出读端临界区，它可能会随着RCU实现的修改而发生语意变化，因此为了预先防止这种情况发生，在新的修改中增加了专门的用于其它内核用户的synchronize_sched函数和只用于RCU使用的synchronize_rcu，现在建议非RCU内核代码部分不使用synchronize_kernel而使用synchronize_sched，RCU代码部分则使用synchronize_rcu，synchronize_kernel之所以存在是为了保证代码兼容性。
synchronize_kernel()
其他非RCU的内核代码使用该函数来等待所有CPU处在可抢占状态，目前功能等同于synchronize_rcu，但现在已经不建议使用，而使用synchronize_sched。
synchronize_sched()
该函数用于等待所有CPU都处在可抢占状态，它能保证正在运行的中断处理函数处理完毕，但不能保证正在运行的softirq处理完毕。注意，synchronize_rcu只保证所有CPU都处理完正在运行的读端临界区。
void fastcall call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
struct rcu_head {
struct rcu_head *next;
void (*func)(struct rcu_head *head);
};
函数call_rcu也由RCU写端调用，它不会使写者阻塞，因而可以在中断上下文或softirq使用。该函数将把函数func挂接到RCU回调函数链上，然后立即返回。一旦所有的CPU都已经完成读端临界区操作，该函数将被调用来释放删除的将绝不在被应用的数据。参数head用于记录回调函数func，一般该结构会作为被RCU保护的数据结构的一个字段，以便省去单独为该结构分配内存的操作。需要指出的是，函数synchronize_rcu的实现实际上使用函数call_rcu。
void fastcall call_rcu_bh(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
函数call_ruc_bh功能几乎与call_rcu完全相同，唯一差别就是它把softirq的完成也当作经历一个quiescent state，因此如果写端使用了该函数，在进程上下文的读端必须使用rcu_read_lock_bh。
#define rcu_dereference(p) ({
typeof(p) _________p1 = p;
smp_read_barrier_depends();
(_________p1);
})
该宏用于在RCU读端临界区获得一个RCU保护的指针，该指针可以在以后安全地引用，内存栅只在alpha架构上才使用。
除了这些API，RCU还增加了链表操作的RCU版本，因为对于RCU，对共享数据的操作必须保证能够被没有使用同步机制的读者看到，所以内存栅是非常必要的。
static inline void list_add_rcu(struct list_head new, struct list_head head)1
该函数把链表项new插入到RCU保护的链表head的开头。使用内存栅保证了在引用这个新插入的链表项之前，新链表项的链接指针的修改对所有读者是可见的。
static inline void list_add_tail_rcu(struct list_head *new,
struct list_head *head)
该函数类似于list_add_rcu，它将把新的链表项new添加到被RCU保护的链表的末尾。
static inline void list_del_rcu(struct list_head *entry)
该函数从RCU保护的链表中移走指定的链表项entry，并且把entry的prev指针设置为LIST_POISON2，但是并没有把entry的next指针设置为LIST_POISON1，因为该指针可能仍然在被读者用于便利该链表。
static inline void list_replace_rcu(struct list_head *old, struct list_head *new)
该函数是RCU新添加的函数，并不存在非RCU版本。它使用新的链表项new取代旧的链表项old，内存栅保证在引用新的链表项之前，它的链接指针的修正对所有读者可见。
list_for_each_rcu(pos, head)
该宏用于遍历由RCU保护的链表head，只要在读端临界区使用该函数，它就可以安全地和其它_rcu链表操作函数（如list_add_rcu）并发运行。
list_for_each_safe_rcu(pos, n, head)
该宏类似于list_for_each_rcu，但不同之处在于它允许安全地删除当前链表项pos。
list_for_each_entry_rcu(pos, head, member)
该宏类似于list_for_each_rcu，不同之处在于它用于遍历指定类型的数据结构链表，当前链表项pos为一包含struct list_head结构的特定的数据结构。
list_for_each_continue_rcu(pos, head)
该宏用于在退出点之后继续遍历由RCU保护的链表head。
static inline void hlist_del_rcu(struct hlist_node *n)
它从由RCU保护的哈希链表中移走链表项n，并设置n的ppre指针为LIST_POISON2，但并没有设置next为LIST_POISON1,因为该指针可能被读者使用用于遍利链表。
static inline void hlist_add_head_rcu(struct hlist_node *n,
struct hlist_head *h)
该函数用于把链表项n插入到被RCU保护的哈希链表的开头，但同时允许读者对该哈希链表的遍历。内存栅确保在引用新链表项之前，它的指针修正对所有读者可见。
hlist_for_each_rcu(pos, head)
该宏用于遍历由RCU保护的哈希链表head，只要在读端临界区使用该函数，它就可以安全地和其它_rcu哈希链表操作函数（如hlist_add_rcu）并发运行。
hlist_for_each_entry_rcu(tpos, pos, head, member)
类似于hlist_for_each_rcu，不同之处在于它用于遍历指定类型的数据结构哈希链表，当前链表项pos为一包含struct list_head结构的特定的数据结构。
下面部分将就 RCU 的几种典型应用情况详细讲解：
- 只有增加和删除的链表操作
在这种应用情况下，绝大部分是对链表的遍历，即读操作，而很少出现的写操作只有增加或删除链表项，并没有对链表项的修改操作，这种情况使用RCU非常容易，从rwlock转换成RCU非常自然。路由表的维护就是这种情况的典型应用，对路由表的操作，绝大部分是路由表查询，而对路由表的写操作也仅仅是增加或删除，因此使用RCU替换原来的rwlock顺理成章。系统调用审计也是这样的情况。
这是一段使用rwlock的系统调用审计部分的读端代码：
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
struct audit_entry *e;
enum audit_state state;
read_lock(&auditsc_lock);
/* Note: audit_netlink_sem held by caller. */
list_for_each_entry(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
read_unlock(&auditsc_lock);
return state;
}
}
read_unlock(&auditsc_lock);
return AUDIT_BUILD_CONTEXT;
}
使用RCU后将变成：
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
struct audit_entry *e;
enum audit_state state;
rcu_read_lock();
/* Note: audit_netlink_sem held by caller. */
list_for_each_entry_rcu(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
rcu_read_unlock();
return state;
}
}
rcu_read_unlock();
return AUDIT_BUILD_CONTEXT;
}
这种转换非常直接，使用rcu_read_lock和rcu_read_unlock分别替换read_lock和read_unlock，链表遍历函数使用_rcu版本替换就可以了。
使用rwlock的写端代码：
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
write_lock(&auditsc_lock);
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
list_del(&e->list);
write_unlock(&auditsc_lock);
return 0;
}
}
write_unlock(&auditsc_lock);
return -EFAULT; /* No matching rule */
}
static inline int audit_add_rule(struct audit_entry *entry,
struct list_head *list)
{
write_lock(&auditsc_lock);
if (entry->rule.flags & AUDIT_PREPEND) {
entry->rule.flags &= ~AUDIT_PREPEND;
list_add(&entry->list, list);
} else {
list_add_tail(&entry->list, list);
}
write_unlock(&auditsc_lock);
return 0;
}
使用RCU后写端代码变成为：
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
/* Do not use the _rcu iterator here, since this is the only
* deletion routine. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
list_del_rcu(&e->list);
call_rcu(&e->rcu, audit_free_rule, e);
return 0;
}
}
return -EFAULT; /* No matching rule */
}
static inline int audit_add_rule(struct audit_entry *entry,
struct list_head *list)
{
if (entry->rule.flags & AUDIT_PREPEND) {
entry->rule.flags &= ~AUDIT_PREPEND;
list_add_rcu(&entry->list, list);
} else {
list_add_tail_rcu(&entry->list, list);
}
return 0;
}
对于链表删除操作，list_del替换为list_del_rcu和call_rcu，这是因为被删除的链表项可能还在被别的读者引用，所以不能立即删除，必须等到所有读者经历一个quiescent state才可以删除。另外，list_for_each_entry并没有被替换为list_for_each_entry_rcu，这是因为，只有一个写者在做链表删除操作，因此没有必要使用_rcu版本。
通常情况下，write_lock和write_unlock应当分别替换成spin_lock和spin_unlock，但是对于只是对链表进行增加和删除操作而且只有一个写者的写端，在使用了_rcu版本的链表操作API后，rwlock可以完全消除，不需要spinlock来同步读者的访问。对于上面的例子，由于已经有audit_netlink_sem被调用者保持，所以spinlock就没有必要了。
这种情况允许修改结果延后一定时间才可见，而且写者对链表仅仅做增加和删除操作，所以转换成使用RCU非常容易。
2．写端需要对链表条目进行修改操作
如果写者需要对链表条目进行修改，那么就需要首先拷贝要修改的条目，然后修改条目的拷贝，等修改完毕后，再使用条目拷贝取代要修改的条目，要修改条目将被在经历一个grace period后安全删除。
对于系统调用审计代码，并没有这种情况。这里假设有修改的情况，那么使用rwlock的修改代码应当如下：
static inline int audit_upd_rule(struct audit_rule *rule,
struct list_head *list,
__u32 newaction,
__u32 newfield_count)
{
struct audit_entry *e;
struct audit_newentry *ne;
write_lock(&auditsc_lock);
/* Note: audit_netlink_sem held by caller. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
e->rule.action = newaction;
e->rule.file_count = newfield_count;
write_unlock(&auditsc_lock);
return 0;
}
}
write_unlock(&auditsc_lock);
return -EFAULT; /* No matching rule */
}
如果使用RCU，修改代码应当为；
static inline int audit_upd_rule(struct audit_rule *rule,
struct list_head *list,
__u32 newaction,
__u32 newfield_count)
{
struct audit_entry *e;
struct audit_newentry *ne;
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
if (ne == NULL)
return -ENOMEM;
audit_copy_rule(&ne->rule, &e->rule);
ne->rule.action = newaction;
ne->rule.file_count = newfield_count;
list_replace_rcu(e, ne);
call_rcu(&e->rcu, audit_free_rule, e);
return 0;
}
}
return -EFAULT; /* No matching rule */
}
3．修改操作立即可见
前面两种情况，读者能够容忍修改可以在一段时间后看到，也就说读者在修改后某一时间段内，仍然看到的是原来的数据。在很多情况下，读者不能容忍看到旧的数据，这种情况下，需要使用一些新措施，如System V IPC，它在每一个链表条目中增加了一个deleted字段，标记该字段是否删除，如果删除了，就设置为真，否则设置为假，当代码在遍历链表时，核对每一个条目的deleted字段，如果为真，就认为它是不存在的。
还是以系统调用审计代码为例，如果它不能容忍旧数据，那么，读端代码应该修改为：
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
struct audit_entry *e;
enum audit_state state;
rcu_read_lock();
list_for_each_entry_rcu(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
spin_lock(&e->lock);
if (e->deleted) {
spin_unlock(&e->lock);
rcu_read_unlock();
return AUDIT_BUILD_CONTEXT;
}
rcu_read_unlock();
return state;
}
}
rcu_read_unlock();
return AUDIT_BUILD_CONTEXT;
}
注意，对于这种情况，每一个链表条目都需要一个spinlock保护，因为删除操作将修改条目的deleted标志。此外，该函数如果搜索到条目，返回时应当保持该条目的锁，因为只有这样，才能看到新的修改的数据，否则，仍然可能看到旧的数据。
写端的删除操作将变成：
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
/* Do not use the _rcu iterator here, since this is the only
* deletion routine. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
spin_lock(&e->lock);
list_del_rcu(&e->list);
e->deleted = 1;
spin_unlock(&e->lock);
call_rcu(&e->rcu, audit_free_rule, e);
return 0;
}
}
return -EFAULT; / No matching rule
删除条目时，需要标记该条目为已删除。这样读者就可以通过该标志立即得知条目是否已经删除.
RCU是2.6内核引入的新的锁机制，在绝大部分为读而只有极少部分为写的情况下，它是非常高效的，因此在路由表维护、系统调用审计、SELinux的AVC、dcache和IPC等代码部分中，使用它来取代rwlock来获得更高的性能。但是，它也有缺点，延后的删除或释放将占用一些内存，尤其是对嵌入式系统，这可能是非常昂贵的内存开销。此外，写者的开销比较大，尤其是对于那些无法容忍旧数据的情况以及不只一个写者的情况，写者需要spinlock或其他的锁机制来与其他写者同步。
九，顺序锁(seqlock)
顺序锁简介
顺序锁也是对读写锁的一种优化，对于顺序锁，读者绝不会被写者阻塞，也就说，读者可以在写者对被顺序锁保护的共享资源进行写操作时仍然可以继续读，而不必等待写者完成写操作，写者也不需要等待所有读者完成读操作才去进行写操作。但是，写者与写者之间仍然是互斥的，即如果有写者在进行写操作，其他写者必须自旋在那里，直到写者释放了顺序锁。
这种锁有一个限制，它必须要求被保护的共享资源不含有指针，因为写者可能使得指针失效，但读者如果正要访问该指针，将导致OOPs。
如果读者在读操作期间，写者已经发生了写操作，那么，读者必须重新读取数据，以便确保得到的数据是完整的。
这种锁对于读写同时进行的概率比较小的情况，性能是非常好的，而且它允许读写同时进行，因而更大地提高了并发性。
顺序锁的API
void write_seqlock(seqlock_t *sl);
写者在访问被顺序锁s1保护的共享资源前需要调用该函数来获得顺序锁s1。它实际功能上等同于spin_lock，只是增加了一个对顺序锁顺序号的加1操作，以便读者能够检查出是否在读期间有写者访问过。
void write_sequnlock(seqlock_t *sl);
写者在访问完被顺序锁s1保护的共享资源后需要调用该函数来释放顺序锁s1。它实际功能上等同于spin_unlock，只是增加了一个对顺序锁顺序号的加1操作，以便读者能够检查出是否在读期间有写者访问过。
写者使用顺序锁的模式如下：
write_seqlock(&seqlock_a);
//写操作代码块
…
write_sequnlock(&seqlock_a);
因此，对写者而言，它的使用与spinlock相同。
int write_tryseqlock(seqlock_t *sl);
写者在访问被顺序锁s1保护的共享资源前也可以调用该函数来获得顺序锁s1。它实际功能上等同于spin_trylock，只是如果成功获得锁后，该函数增加了一个对顺序锁顺序号的加1操作，以便读者能够检查出是否在读期间有写者访问过。
unsigned read_seqbegin(const seqlock_t *sl);
读者在对被顺序锁s1保护的共享资源进行访问前需要调用该函数。读者实际没有任何得到锁和释放锁的开销，该函数只是返回顺序锁s1的当前顺序号。
int read_seqretry(const seqlock_t *sl, unsigned iv);
读者在访问完被顺序锁s1保护的共享资源后需要调用该函数来检查，在读访问期间是否有写者访问了该共享资源，如果是，读者就需要重新进行读操作，否则，读者成功完成了读操作。
因此，读者使用顺序锁的模式如下：
do {
seqnum = read_seqbegin(&seqlock_a);
//读操作代码块
...
} while (read_seqretry(&seqlock_a, seqnum));
write_seqlock_irqsave(lock, flags)
写者也可以用该宏来获得顺序锁lock，与write_seqlock不同的是，该宏同时还把标志寄存器的值保存到变量flags中，并且失效了本地中断。
write_seqlock_irq(lock)
写者也可以用该宏来获得顺序锁lock，与write_seqlock不同的是，该宏同时还失效了本地中断。与write_seqlock_irqsave不同的是，该宏不保存标志寄存器。
write_seqlock_bh(lock)
写者也可以用该宏来获得顺序锁lock，与write_seqlock不同的是，该宏同时还失效了本地软中断。
write_sequnlock_irqrestore(lock, flags)
写者也可以用该宏来释放顺序锁lock，与write_sequnlock不同的是，该宏同时还把标志寄存器的值恢复为变量flags的值。它必须与write_seqlock_irqsave配对使用。
write_sequnlock_irq(lock)
写者也可以用该宏来释放顺序锁lock，与write_sequnlock不同的是，该宏同时还使能本地中断。它必须与write_seqlock_irq配对使用。
write_sequnlock_bh(lock)
写者也可以用该宏来释放顺序锁lock，与write_sequnlock不同的是，该宏同时还使能本地软中断。它必须与write_seqlock_bh配对使用。
read_seqbegin_irqsave(lock, flags)
读者在对被顺序锁lock保护的共享资源进行访问前也可以使用该宏来获得顺序锁lock的当前顺序号，与read_seqbegin不同的是，它同时还把标志寄存器的值保存到变量flags中，并且失效了本地中断。注意，它必须与read_seqretry_irqrestore配对使用。
read_seqretry_irqrestore(lock, iv, flags)
读者在访问完被顺序锁lock保护的共享资源进行访问后也可以使用该宏来检查，在读访问期间是否有写者访问了该共享资源，如果是，读者就需要重新进行读操作，否则，读者成功完成了读操作。它与read_seqretry不同的是，该宏同时还把标志寄存器的值恢复为变量flags的值。注意，它必须与read_seqbegin_irqsave配对使用。
因此，读者使用顺序锁的模式也可以为：
do {
seqnum = read_seqbegin_irqsave(&seqlock_a, flags);
//读操作代码块
...
} while (read_seqretry_irqrestore(&seqlock_a, seqnum, flags));
读者和写者所使用的API的几个版本应该如何使用与自旋锁的类似。
如果写者在操作被顺序锁保护的共享资源时已经保持了互斥锁保护对共享数据的写操作，即写者与写者之间已经是互斥的，但读者仍然可以与写者同时访问，那么这种情况仅需要使用顺序计数（seqcount），而不必要spinlock。
顺序计数的API
unsigned read_seqcount_begin(const seqcount_t *s);
读者在对被顺序计数保护的共享资源进行读访问前需要使用该函数来获得当前的顺序号。
int read_seqcount_retry(const seqcount_t *s, unsigned iv);
读者在访问完被顺序计数s保护的共享资源后需要调用该函数来检查，在读访问期间是否有写者访问了该共享资源，如果是，读者就需要重新进行读操作，否则，读者成功完成了读操作。
因此，读者使用顺序计数的模式如下：
do {
seqnum = read_seqbegin_count(&seqcount_a);
//读操作代码块
...
} while (read_seqretry(&seqcount_a, seqnum));
void write_seqcount_begin(seqcount_t *s);
写者在访问被顺序计数保护的共享资源前需要调用该函数来对顺序计数的顺序号加1，以便读者能够检查出是否在读期间有写者访问过。
void write_seqcount_end(seqcount_t *s);
写者在访问完被顺序计数保护的共享资源后需要调用该函数来对顺序计数的顺序号加1，以便读者能够检查出是否在读期间有写者访问过。
写者使用顺序计数的模式为：
write_seqcount_begin(&seqcount_a);
//写操作代码块
…
write_seqcount_end(&seqcount_a);
需要特别提醒，顺序计数的使用必须非常谨慎，只有确定在访问共享数据时已经保持了互斥锁才可以使用。
内核在写和读netdevice的名字时分别使用dev_change_name和netdev_get_name中使用了该方法。而dev_change_name由dev_ifsioc调用，其如下所示使用互斥锁进行了保护。
rtnl_lock(); //内部即互斥锁
ret = dev_ifsioc(net, &ifr, cmd)
rtnl_unlock();
#define local_irq_enable() do { raw_local_irq_enable(); } while (0)
#define local_irq_disable() do { raw_local_irq_disable(); } while (0)
#define raw_local_irq_disable() arch_local_irq_disable()
#define raw_local_irq_enable() arch_local_irq_enable()
可以看到这个与体系结构有关
禁止内核抢占就比较简单了，就是防止当前进程不会突然被另一个进程抢占。在Linux的实现就是preempt_disable()和preempt_enable()函数
#define preempt_disable()
do {
//增加preempt_count
inc_preempt_count();
//保证先加了preempt_count才进行以后的操作
barrier();
} while (0)
#define preempt_enable()
do {
preempt_enable_no_resched();
barrier();
//检查当前进程是否可抢占
preempt_check_resched();
} while
不管是禁止中断还是禁止内核抢占，都是为了提供内核同步，但是他们都没有提供任何保护机制来防止其它处理器的并发访问。Linux支持多处理器，因此，内核代码一般都需要获取某种锁，防止来自其他处理器对共享数据的并发访问，而禁止中断提供保护机制，这是防止来自其他中断处理程序的并发访问。
前面说的都是概念，现在我们来讨论几个问题：
1.在单处理器条件下，为什么禁止中断就可以禁止内核抢占？
首先来回顾一下内核抢占发生在哪些时候：
- 在中断返回内核空间的时候，这个没什么好说的，跟中断密切相关，没了中断就不会发生
- 内核显式调用schedule()（可抢占或阻塞）
我们先搞清楚一件事，就是我们说禁止中断可以禁止内核抢占只是说禁止任何意外的抢占，如果进程自己要调用schedule函数，那谁也拦不住，事实上调用schedule这个函数本来就要禁止中断，所以剩下的就是考虑创建或者唤醒一个更高优先级的进程，或者调用信号量、完成量，所有的这些情况都要通过try_to_wake_up函数唤醒另一个进程，但是这个函数真正干的事只是设置了一下need_resched这个函数，并没有真的调用schedule函数，调用是在系统调用返回用户空间的时候进行的，所以跟内核抢占也没啥关系，所以从这些方面来说，禁止中断是可以禁止内核抢占的。
2.自旋锁关中断后，为什么要再禁止抢占?
假设有这么个情况：
1)CPU-1在进程A的上下文调用了spin_lock_irqsave；
2)CPU-2调用wake_up_process唤醒了CPU-1上的进程B，由于进程B的优先级高于进程A，进程A的TIF_NEED_RESCHED标记被设置。（CPU-2还会用IPI通知CPU-1进行resched，但是CPU-1禁用了中断而不会响应）；
3)CPU-1调用了某某函数，这个函数包含了preempt_disable和preempt_enable（没有规定关中断的情况下不能调用这样的函数吧~）；
那么，如果spin_lock_irqsave没有preempt_disable，第3步中的preempt_enable将触发preempt_check_resched，从而让进程B抢占掉进程A。
总之就是只有关了抢占，才能保证在临界区成对出现的preempt_disable()/preempt_enable()（preempt_enable()也是一个潜在的主动调度的测试点）不会造成伤害。不然这种代码就不能放在临界区中了。
Linux可以使用互斥信号量来表示互斥锁，那就是通过宏DECLARE_MUTEX来定义一个互斥信号量，因为DECLARE_MUTEX这个宏，Marcin Slusarz在08年提交的了一个patch，Marcin Slusarz认为DECLARE_MUTEX宏会误导开发者，所以建议将DECLARE_MUTEX修改成DEFINE_SEMAPHORE，这个提议最终被内核社区所接受，在2.6.36版本后的内核就没有DECLARE_MUTEX这个宏了，取而代之的是DEFINE_SEMAPHORE宏，在后来同互斥信号量相关的init_MUTEX、init_MUTEX_LOCKED也从文件中移除了。
虽然可以使用信号量来表示互斥锁，但是互斥锁其实是存在的，只是前面的宏DECLARE_MUTEX因为会引起歧义，所以修改成了DEFINE_SEMAPHORE，mutex在2.6.16版本就融入到了主内核中了，使用mutex需要包含头文件.
禁止中断和禁止抢占的简介
禁止中断指的是Linux内核提供了一组接口用于操作机器上的中断状态。这些接口为我们提供了能够禁止当前处理器的中断系统，或者屏蔽掉整个机器的一条中断线的能力。通过禁止中断，可以确保某个中断处理程序不会抢占当前的代码。控制中断系统在Linux的实现有很多，以local_irq_disable()和 local_irq_enable()函数为例
原文地址：https://zhuanlan.zhihu.com/p/527184125
