linux进程互斥？linux卸载软件包命令

如何实现linux下多线程之间的互斥与同步

Linux设备驱动中必须解决的一个问题是多个进程对共享资源的并发访问，并发访问会导致竞态，linux提供了多种解决竞态问题的方式，这些方式适合不同的应用场景。

Linux内核是多进程、多线程的操作系统，它提供了相当完整的内核同步方法。内核同步方法列表如下：

中断屏蔽

原子操作

自旋锁

读写自旋锁

顺序锁

信号量

读写信号量

BKL（大内核锁）

Seq锁

一、并发与竞态：

定义：

并发（concurrency）指的是多个执行单元同时、并行被执行，而并发的执行单元对共享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions）。

在linux中，主要的竞态发生在如下几种情况：

1、对称多处理器（SMP）多个CPU

特点是多个CPU使用共同的系统总线，因此可访问共同的外设和存储器。

2、单CPU内进程与抢占它的进程

3、中断（硬中断、软中断、Tasklet、底半部）与进程之间

只要并发的多个执行单元存在对共享资源的访问，竞态就有可能发生。

如果中断处理程序访问进程正在访问的资源，则竞态也会会发生。

多个中断之间本身也可能引起并发而导致竞态（中断被更高优先级的中断打断）。

解决竞态问题的途径是保证对共享资源的互斥访问，所谓互斥访问就是指一个执行单元在访问共享资源的时候，其他的执行单元都被禁止访问。

访问共享资源的代码区域被称为临界区，临界区需要以某种互斥机制加以保护，中断屏蔽，原子操作，自旋锁，和信号量都是linux设备驱动中可采用的互斥途径。

临界区和竞争条件：

所谓临界区（critical regions）就是访问和操作共享数据的代码段，为了避免在临界区中并发访问，编程者必须保证这些代码原子地执行——也就是说，代码在执行结束前不可被打断，就如同整个临界区是一个不可分割的指令一样，如果两个执行线程有可能处于同一个临界区中，那么就是程序包含一个bug，如果这种情况发生了，我们就称之为竞争条件（race conditions），避免并发和防止竞争条件被称为同步。

死锁：

死锁的产生需要一定条件：要有一个或多个执行线程和一个或多个资源，每个线程都在等待其中的一个资源，但所有的资源都已经被占用了，所有线程都在相互等待，但它们永远不会释放已经占有的资源，于是任何线程都无法继续，这便意味着死锁的发生。

二、中断屏蔽

在单CPU范围内避免竞态的一种简单方法是在进入临界区之前屏蔽系统的中断。

由于linux内核的进程调度等操作都依赖中断来实现，内核抢占进程之间的并发也就得以避免了。

中断屏蔽的使用方法：

local_irq_disable()//屏蔽中断

//临界区

local_irq_enable()//开中断

特点：

由于linux系统的异步IO，进程调度等很多重要操作都依赖于中断，在屏蔽中断期间所有的中断都无法得到处理，因此长时间的屏蔽是很危险的，有可能造成数据丢失甚至系统崩溃，这就要求在屏蔽中断之后，当前的内核执行路径应当尽快地执行完临界区的代码。

中断屏蔽只能禁止本CPU内的中断，因此，并不能解决多CPU引发的竞态，所以单独使用中断屏蔽并不是一个值得推荐的避免竞态的方法，它一般和自旋锁配合使用。

三、原子操作

定义：原子操作指的是在执行过程中不会被别的代码路径所中断的操作。

（原子原本指的是不可分割的微粒，所以原子操作也就是不能够被分割的指令）

（它保证指令以“原子”的方式执行而不能被打断）

原子操作是不可分割的，在执行完毕不会被任何其它任务或事件中断。在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。这也是某些CPU指令系统中引入了test_and_set、test_and_clear等指令用于临界资源互斥的原因。但是，在对称多处理器(Symmetric Multi-Processor)结构中就不同了，由于系统中有多个处理器在独立地运行，即使能在单条指令中完成的操作也有可能受到干扰。我们以decl(递减指令)为例，这是一个典型的"读－改－写"过程，涉及两次内存访问。

通俗理解：

原子操作，顾名思义，就是说像原子一样不可再细分。一个操作是原子操作，意思就是说这个操作是以原子的方式被执行，要一口气执行完，执行过程不能够被OS的其他行为打断，是一个整体的过程，在其执行过程中，OS的其它行为是插不进来的。

分类：linux内核提供了一系列函数来实现内核中的原子操作，分为整型原子操作和位原子操作，共同点是：在任何情况下操作都是原子的，内核代码可以安全的调用它们而不被打断。

原子整数操作：

针对整数的原子操作只能对atomic_t类型的数据进行处理，在这里之所以引入了一个特殊的数据类型，而没有直接使用C语言的int型，主要是出于两个原因：

第一、让原子函数只接受atomic_t类型的操作数，可以确保原子操作只与这种特殊类型数据一起使用，同时，这也确保了该类型的数据不会被传递给其它任何非原子函数；

第二、使用atomic_t类型确保编译器不对相应的值进行访问优化——这点使得原子操作最终接收到正确的内存地址，而不是一个别名，最后就是在不同体系结构上实现原子操作的时候，使用atomic_t可以屏蔽其间的差异。

原子整数操作最常见的用途就是实现计数器。

另一点需要说明原子操作只能保证操作是原子的，要么完成，要么不完成，不会有操作一半的可能，但原子操作并不能保证操作的顺序性，即它不能保证两个操作是按某个顺序完成的。如果要保证原子操作的顺序性，请使用内存屏障指令。

atomic_t和ATOMIC_INIT(i)定义

typedef struct{ volatile int counter;} atomic_t;

#define ATOMIC_INIT(i){(i)}

在你编写代码的时候，能使用原子操作的时候，就尽量不要使用复杂的加锁机制，对多数体系结构来讲，原子操作与更复杂的同步方法相比较，给系统带来的开销小，对高速缓存行的影响也小，但是，对于那些有高性能要求的代码，对多种同步方法进行测试比较，不失为一种明智的作法。

原子位操作：

针对位这一级数据进行操作的函数，是对普通的内存地址进行操作的。它的参数是一个指针和一个位号。

为方便其间，内核还提供了一组与上述操作对应的非原子位函数，非原子位函数与原子位函数的操作完全相同，但是，前者不保证原子性，且其名字前缀多两个下划线。例如，与test_bit()对应的非原子形式是_test_bit()，如果你不需要原子性操作（比如，如果你已经用锁保护了自己的数据），那么这些非原子的位函数相比原子的位函数可能会执行得更快些。

四、自旋锁

自旋锁的引入：

如果每个临界区都能像增加变量这样简单就好了，可惜现实不是这样，而是临界区可以跨越多个函数，例如：先得从一个数据结果中移出数据，对其进行格式转换和解析，最后再把它加入到另一个数据结构中，整个执行过程必须是原子的，在数据被更新完毕之前，不能有其他代码读取这些数据，显然，简单的原子操作是无能为力的（在单处理器系统(UniProcessor)中，能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间），这就需要使用更为复杂的同步方法——锁来提供保护。

自旋锁的介绍：

Linux内核中最常见的锁是自旋锁（spin lock），自旋锁最多只能被一个可执行线程持有，如果一个执行线程试图获得一个被争用（已经被持有）的自旋锁，那么该线程就会一直进行忙循环—旋转—等待锁重新可用，要是锁未被争用，请求锁的执行线程便能立刻得到它，继续执行，在任意时间，自旋锁都可以防止多于一个的执行线程同时进入理解区，注意同一个锁可以用在多个位置—例如，对于给定数据的所有访问都可以得到保护和同步。

一个被争用的自旋锁使得请求它的线程在等待锁重新可用时自旋（特别浪费处理器时间），所以自旋锁不应该被长时间持有，事实上，这点正是使用自旋锁的初衷，在短期间内进行轻量级加锁，还可以采取另外的方式来处理对锁的争用：让请求线程睡眠，直到锁重新可用时再唤醒它，这样处理器就不必循环等待，可以去执行其他代码，这也会带来一定的开销——这里有两次明显的上下文切换，被阻塞的线程要换出和换入。因此，持有自旋锁的时间最好小于完成两次上下文切换的耗时，当然我们大多数人不会无聊到去测量上下文切换的耗时，所以我们让持有自旋锁的时间应尽可能的短就可以了，信号量可以提供上述第二种机制，它使得在发生争用时，等待的线程能投入睡眠，而不是旋转。

自旋锁可以使用在中断处理程序中（此处不能使用信号量，因为它们会导致睡眠），在中断处理程序中使用自旋锁时，一定要在获取锁之前，首先禁止本地中断（在当前处理器上的中断请求），否则，中断处理程序就会打断正持有锁的内核代码，有可能会试图去争用这个已经持有的自旋锁，这样以来，中断处理程序就会自旋，等待该锁重新可用，但是锁的持有者在这个中断处理程序执行完毕前不可能运行，这正是我们在前一章节中提到的双重请求死锁，注意，需要关闭的只是当前处理器上的中断，如果中断发生在不同的处理器上，即使中断处理程序在同一锁上自旋，也不会妨碍锁的持有者（在不同处理器上）最终释放锁。

自旋锁的简单理解：

理解自旋锁最简单的方法是把它作为一个变量看待，该变量把一个临界区或者标记为“我当前正在运行，请稍等一会”或者标记为“我当前不在运行，可以被使用”。如果A执行单元首先进入例程，它将持有自旋锁，当B执行单元试图进入同一个例程时，将获知自旋锁已被持有，需等到A执行单元释放后才能进入。

自旋锁的API函数：

其实介绍的几种信号量和互斥机制，其底层源码都是使用自旋锁,可以理解为自旋锁的再包装。所以从这里就可以理解为什么自旋锁通常可以提供比信号量更高的性能。

自旋锁是一个互斥设备，他只能会两个值：“锁定”和“解锁”。它通常实现为某个整数之中的单个位。

“测试并设置”的操作必须以原子方式完成。

任何时候，只要内核代码拥有自旋锁，在相关CPU上的抢占就会被禁止。

适用于自旋锁的核心规则：

（1）任何拥有自旋锁的代码都必须使原子的，除服务中断外（某些情况下也不能放弃CPU,如中断服务也要获得自旋锁。为了避免这种锁陷阱，需要在拥有自旋锁时禁止中断），不能放弃CPU（如休眠，休眠可发生在许多无法预期的地方）。否则CPU将有可能永远自旋下去（死机）。

（2）拥有自旋锁的时间越短越好。

需要强调的是，自旋锁别设计用于多处理器的同步机制，对于单处理器（对于单处理器并且不可抢占的内核来说，自旋锁什么也不作），内核在编译时不会引入自旋锁机制，对于可抢占的内核，它仅仅被用于设置内核的抢占机制是否开启的一个开关，也就是说加锁和解锁实际变成了禁止或开启内核抢占功能。如果内核不支持抢占，那么自旋锁根本就不会编译到内核中。

内核中使用spinlock_t类型来表示自旋锁，它定义在：

typedef struct{

raw_spinlock_t raw_lock;

#if defined(CONFIG_PREEMPT)&& defined(CONFIG_SMP)

unsigned int break_lock;

#endif

} spinlock_t;

对于不支持SMP的内核来说，struct raw_spinlock_t什么也没有，是一个空结构。对于支持多处理器的内核来说，struct raw_spinlock_t定义为

typedef struct{

unsigned int slock;

} raw_spinlock_t;

slock表示了自旋锁的状态，“1”表示自旋锁处于解锁状态（UNLOCK），“0”表示自旋锁处于上锁状态（LOCKED）。

break_lock表示当前是否由进程在等待自旋锁，显然，它只有在支持抢占的SMP内核上才起作用。

自旋锁的实现是一个复杂的过程，说它复杂不是因为需要多少代码或逻辑来实现它，其实它的实现代码很少。自旋锁的实现跟体系结构关系密切，核心代码基本也是由汇编语言写成，与体协结构相关的核心代码都放在相关的目录下，比如。对于我们驱动程序开发人员来说，我们没有必要了解这么spinlock的内部细节，如果你对它感兴趣，请参考阅读Linux内核源代码。对于我们驱动的spinlock接口，我们只需包括头文件。在我们详细的介绍spinlock的API之前，我们先来看看自旋锁的一个基本使用格式：

#include

spinlock_t lock= SPIN_LOCK_UNLOCKED;

spin_lock(&lock);

....

spin_unlock(&lock);

从使用上来说，spinlock的API还很简单的，一般我们会用的的API如下表，其实它们都是定义在中的宏接口，真正的实现在中

#include

SPIN_LOCK_UNLOCKED

DEFINE_SPINLOCK

spin_lock_init( spinlock_t*)

spin_lock(spinlock_t*)

spin_unlock(spinlock_t*)

spin_lock_irq(spinlock_t*)

spin_unlock_irq(spinlock_t*)

spin_lock_irqsace(spinlock_t*，unsigned long flags)

spin_unlock_irqsace(spinlock_t*, unsigned long flags)

spin_trylock(spinlock_t*)

spin_is_locked(spinlock_t*)

•初始化

spinlock有两种初始化形式，一种是静态初始化，一种是动态初始化。对于静态的spinlock对象，我们用 SPIN_LOCK_UNLOCKED来初始化，它是一个宏。当然，我们也可以把声明spinlock和初始化它放在一起做，这就是 DEFINE_SPINLOCK宏的工作，因此，下面的两行代码是等价的。

DEFINE_SPINLOCK(lock);

spinlock_t lock= SPIN_LOCK_UNLOCKED;

spin_lock_init函数一般用来初始化动态创建的spinlock_t对象，它的参数是一个指向spinlock_t对象的指针。当然，它也可以初始化一个静态的没有初始化的spinlock_t对象。

spinlock_t*lock

......

spin_lock_init(lock);

•获取锁

内核提供了三个函数用于获取一个自旋锁。

spin_lock：获取指定的自旋锁。

spin_lock_irq：禁止本地中断并获取自旋锁。

spin_lock_irqsace：保存本地中断状态，禁止本地中断并获取自旋锁，返回本地中断状态。

自旋锁是可以使用在中断处理程序中的，这时需要使用具有关闭本地中断功能的函数，我们推荐使用 spin_lock_irqsave，因为它会保存加锁前的中断标志，这样就会正确恢复解锁时的中断标志。如果spin_lock_irq在加锁时中断是关闭的，那么在解锁时就会错误的开启中断。

另外两个同自旋锁获取相关的函数是：

spin_trylock()：尝试获取自旋锁，如果获取失败则立即返回非0值，否则返回0。

spin_is_locked()：判断指定的自旋锁是否已经被获取了。如果是则返回非0，否则，返回0。

•释放锁

同获取锁相对应，内核提供了三个相对的函数来释放自旋锁。

spin_unlock：释放指定的自旋锁。

spin_unlock_irq：释放自旋锁并激活本地中断。

spin_unlock_irqsave：释放自旋锁，并恢复保存的本地中断状态。

五、读写自旋锁

如果临界区保护的数据是可读可写的，那么只要没有写操作，对于读是可以支持并发操作的。对于这种只要求写操作是互斥的需求，如果还是使用自旋锁显然是无法满足这个要求（对于读操作实在是太浪费了）。为此内核提供了另一种锁－读写自旋锁，读自旋锁也叫共享自旋锁，写自旋锁也叫排他自旋锁。

读写自旋锁是一种比自旋锁粒度更小的锁机制，它保留了“自旋”的概念，但是在写操作方面，只能最多有一个写进程，在读操作方面，同时可以有多个读执行单元，当然，读和写也不能同时进行。

读写自旋锁的使用也普通自旋锁的使用很类似，首先要初始化读写自旋锁对象：

//静态初始化

rwlock_t rwlock= RW_LOCK_UNLOCKED;

//动态初始化

rwlock_t*rwlock;

...

rw_lock_init(rwlock);

在读操作代码里对共享数据获取读自旋锁：

read_lock(&rwlock);

...

read_unlock(&rwlock);

在写操作代码里为共享数据获取写自旋锁：

write_lock(&rwlock);

...

write_unlock(&rwlock);

需要注意的是，如果有大量的写操作，会使写操作自旋在写自旋锁上而处于写饥饿状态（等待读自旋锁的全部释放），因为读自旋锁会自由的获取读自旋锁。

读写自旋锁的函数类似于普通自旋锁，这里就不一一介绍了，我们把它列在下面的表中。

RW_LOCK_UNLOCKED

rw_lock_init(rwlock_t*)

read_lock(rwlock_t*)

read_unlock(rwlock_t*)

read_lock_irq(rwlock_t*)

read_unlock_irq(rwlock_t*)

read_lock_irqsave(rwlock_t*, unsigned long)

read_unlock_irqsave(rwlock_t*, unsigned long)

write_lock(rwlock_t*)

write_unlock(rwlock_t*)

write_lock_irq(rwlock_t*)

write_unlock_irq(rwlock_t*)

write_lock_irqsave(rwlock_t*, unsigned long)

write_unlock_irqsave(rwlock_t*, unsigned long)

rw_is_locked(rwlock_t*)

六、顺序琐

顺序琐（seqlock）是对读写锁的一种优化，若使用顺序琐，读执行单元绝不会被写执行单元阻塞，也就是说，读执行单元可以在写执行单元对被顺序琐保护的共享资源进行写操作时仍然可以继续读，而不必等待写执行单元完成写操作，写执行单元也不需要等待所有读执行单元完成读操作才去进行写操作。

但是，写执行单元与写执行单元之间仍然是互斥的，即如果有写执行单元在进行写操作，其它写执行单元必须自旋在哪里，直到写执行单元释放了顺序琐。

如果读执行单元在读操作期间，写执行单元已经发生了写操作，那么，读执行单元必须重新读取数据，以便确保得到的数据是完整的，这种锁在读写同时进行的概率比较小时，性能是非常好的，而且它允许读写同时进行，因而更大的提高了并发性，

注意，顺序琐由一个限制，就是它必须被保护的共享资源不含有指针，因为写执行单元可能使得指针失效，但读执行单元如果正要访问该指针，将导致Oops。

七、信号量

Linux中的信号量是一种睡眠锁，如果有一个任务试图获得一个已经被占用的信号量时，信号量会将其推进一个等待队列，然后让其睡眠，这时处理器能重获自由，从而去执行其它代码，当持有信号量的进程将信号量释放后，处于等待队列中的哪个任务被唤醒，并获得该信号量。

信号量，或旗标，就是我们在操作系统里学习的经典的P/V原语操作。

P：如果信号量值大于0，则递减信号量的值，程序继续执行，否则，睡眠等待信号量大于0。

V：递增信号量的值，如果递增的信号量的值大于0，则唤醒等待的进程。

信号量的值确定了同时可以有多少个进程可以同时进入临界区，如果信号量的初始值始1，这信号量就是互斥信号量（MUTEX）。对于大于1的非0值信号量，也可称为计数信号量（counting semaphore）。对于一般的驱动程序使用的信号量都是互斥信号量。

类似于自旋锁，信号量的实现也与体系结构密切相关，具体的实现定义在头文件中，对于x86_32系统来说，它的定义如下：

struct semaphore{

atomic_t count;

int sleepers;

wait_queue_head_t wait;

};

信号量的初始值count是atomic_t类型的，这是一个原子操作类型，它也是一个内核同步技术，可见信号量是基于原子操作的。我们会在后面原子操作部分对原子操作做详细介绍。

信号量的使用类似于自旋锁，包括创建、获取和释放。我们还是来先展示信号量的基本使用形式：

static DECLARE_MUTEX(my_sem);

......

if(down_interruptible(&my_sem))

{

return-ERESTARTSYS;

}

......

up(&my_sem)

Linux内核中的信号量函数接口如下：

static DECLARE_SEMAPHORE_GENERIC(name, count);

static DECLARE_MUTEX(name);

seam_init(struct semaphore*, int);

init_MUTEX(struct semaphore*);

init_MUTEX_LOCKED(struct semaphore*)

down_interruptible(struct semaphore*);

down(struct semaphore*)

down_trylock(struct semaphore*)

up(struct semaphore*)

•初始化信号量

信号量的初始化包括静态初始化和动态初始化。静态初始化用于静态的声明并初始化信号量。

static DECLARE_SEMAPHORE_GENERIC(name, count);

static DECLARE_MUTEX(name);

对于动态声明或创建的信号量，可以使用如下函数进行初始化：

seam_init(sem, count);

init_MUTEX(sem);

init_MUTEX_LOCKED(struct semaphore*)

显然，带有MUTEX的函数始初始化互斥信号量。LOCKED则初始化信号量为锁状态。

•使用信号量

信号量初始化完成后我们就可以使用它了

down_interruptible(struct semaphore*);

down(struct semaphore*)

down_trylock(struct semaphore*)

up(struct semaphore*)

down函数会尝试获取指定的信号量，如果信号量已经被使用了，则进程进入不可中断的睡眠状态。down_interruptible则会使进程进入可中断的睡眠状态。关于进程状态的详细细节，我们在内核的进程管理里在做详细介绍。

down_trylock尝试获取信号量，如果获取成功则返回0，失败则会立即返回非0。

当退出临界区时使用up函数释放信号量，如果信号量上的睡眠队列不为空，则唤醒其中一个等待进程。

八、读写信号量

类似于自旋锁，信号量也有读写信号量。读写信号量API定义在头文件中，它的定义其实也是体系结构相关的，因此具体实现定义在头文件中，以下是x86的例子：

struct rw_semaphore{

signed long count;

spinlock_t wait_lock;

struct list_head wait_list;

};

请教一个Linux多进程访问动态库的互斥问题

请教一个Linux多进程访问动态库的互斥问题

首先要了解并发。

并发进程间的关系可以是无关的，也可以是有交往的。并发进程间无关是指它们是各自独立的，即如果一个进程的执行不影响其他进程的执行，且与其他进程的进展情况无关，不需要特别的控制；并发进程间有交往是指一个进程的执行可能影响其他进程的执行结果，即一个进程的执行依赖其他进程的进展情况。有交往的并发进程一定共享某些资源。

进程之间互相竞争某一个资源，这种关系就称为进程的互斥，也就是说对于某个系统资源，如果一个进程正在使用，其他的进程就必须等待其用完，不能同时使用。例如，A，B两个进程共享一台打印机，如果系统已经将打印机分配给了A进程，当B进程需要打印时因得不到打印机而阻塞，只有A进程将打印机释放后，系统才将B进程唤醒，B进程才有可能获得打印机。

并发进程使用共享资源时，除了竞争之外有协作，要利用互通消息的办法来控制执行速度，使相互协作的进程正确工作。进程之间的相互合作来完成某一任务，把这种关系称为进程的同步。例如（生产者和消费者）A，B两个进程通过一个缓冲区合作完成一项任务，A进程将数据送入缓冲区后通知B进程缓冲区中有数据，B进程从缓冲区中取走数据再通知A进程缓冲区现为空。

Linux系统中的进程调度介绍

操作系统要实现多进程，进程调度必不可少。

有人说，进程调度是操作系统中最为重要的一个部分。我觉得这种说法说得太绝对了一点，就像很多人动辄就说"某某函数比某某函数效率高XX倍"一样，脱离了实际环境，这些结论是比较片面的。

而进程调度究竟有多重要呢?首先，我们需要明确一点：进程调度是对TASK_RUNNING状态的进程进行调度(参见《linux进程状态浅析》)。如果进程不可执行(正在睡眠或其他)，那么它跟进程调度没多大关系。

所以，如果你的系统负载非常低，盼星星盼月亮才出现一个可执行状态的进程。那么进程调度也就不会太重要。哪个进程可执行，就让它执行去，没有什么需要多考虑的。

反之，如果系统负载非常高，时时刻刻都有N多个进程处于可执行状态，等待被调度运行。那么进程调度程序为了协调这N个进程的执行，必定得做很多工作。协调得不好，系统的性能就会大打折扣。这个时候，进程调度就是非常重要的。

尽管我们平常接触的很多计算机(如桌面系统、网络服务器、等)负载都比较低，但是linux作为一个通用操作系统，不能假设系统负载低，必须为应付高负载下的进程调度做精心的设计。

当然，这些设计对于低负载(且没有什么实时性要求)的环境，没多大用。极端情况下，如果CPU的负载始终保持0或1(永远都只有一个进程或没有进程需要在CPU上运行)，那么这些设计基本上都是徒劳的。

优先级

现在的操作系统为了协调多个进程的“同时”运行，最基本的手段就是给进程定义优先级。定义了进程的优先级，如果有多个进程同时处于可执行状态，那么谁优先级高谁就去执行，没有什么好纠结的了。

那么，进程的优先级该如何确定呢?有两种方式：由用户程序指定、由内核的调度程序动态调整。(下面会说到)

linux内核将进程分成两个级别：普通进程和实时进程。实时进程的优先级都高于普通进程，除此之外，它们的调度策略也有所不同。

实时进程的调度

实时，原本的涵义是“给定的操作一定要在确定的时间内完成”。重点并不在于操作一定要处理得多快，而是时间要可控(在最坏情况下也不能突破给定的时间)。

这样的“实时”称为“硬实时”，多用于很精密的系统之中(比如什么火箭、导弹之类的)。一般来说，硬实时的系统是相对比较专用的。

像linux这样的通用操作系统显然没法满足这样的要求，中断处理、虚拟内存、等机制的存在给处理时间带来了很大的不确定性。硬件的cache、磁盘寻道、总线争用、也会带来不确定性。

比如考虑“i++;”这么一句C代码。绝大多数情况下，它执行得很快。但是极端情况下还是有这样的可能：

1、i的内存空间未分配，CPU触发缺页异常。而linux在缺页异常的处理代码中试图分配内存时，又可能由于系统内存紧缺而分配失败，导致进程进入睡眠;

2、代码执行过程中硬件产生中断，linux进入中断处理程序而搁置当前进程。而中断处理程序的处理过程中又可能发生新的硬件中断，中断永远嵌套不止……;

等等……

而像linux这样号称实现了“实时”的通用操作系统，其实只是实现了“软实时”，即尽可能地满足进程的实时需求。

如果一个进程有实时需求(它是一个实时进程)，则只要它是可执行状态的，内核就一直让它执行，以尽可能地满足它对CPU的需要，直到它完成所需要做的事情，然后睡眠或退出(变为非可执行状态)。

而如果有多个实时进程都处于可执行状态，则内核会先满足优先级最高的实时进程对CPU的需要，直到它变为非可执行状态。

于是，只要高优先级的实时进程一直处于可执行状态，低优先级的实时进程就一直不能得到CPU;只要一直有实时进程处于可执行状态，普通进程就一直不能得到CPU。

那么，如果多个相同优先级的实时进程都处于可执行状态呢?这时就有两种调度策略可供选择：

1、SCHED_FIFO：先进先出。直到先被执行的进程变为非可执行状态，后来的进程才被调度执行。在这种策略下，先来的进程可以执行sched_yield系统调用，自愿放弃CPU，以让权给后来的进程;

2、SCHED_RR：轮转调度。内核为实时进程分配时间片，在时间片用完时，让下一个进程使用CPU;

强调一下，这两种调度策略以及sched_yield系统调用都仅仅针对于相同优先级的多个实时进程同时处于可执行状态的情况。

在linux下，用户程序可以通过sched_setscheduler系统调用来设置进程的调度策略以及相关调度参数;sched_setparam系统调用则只用于设置调度参数。这两个系统调用要求用户进程具有设置进程优先级的能力(CAP_SYS_NICE，一般来说需要root权限)(参阅capability相关的文章)。

通过将进程的策略设为SCHED_FIFO或SCHED_RR，使得进程变为实时进程。而进程的优先级则是通过以上两个系统调用在设置调度参数时指定的。

对于实时进程，内核不会试图调整其优先级。因为进程实时与否?有多实时?这些问题都是跟用户程序的应用场景相关，只有用户能够回答，内核不能臆断。

综上所述，实时进程的调度是非常简单的。进程的优先级和调度策略都由用户定死了，内核只需要总是选择优先级最高的实时进程来调度执行即可。唯一稍微麻烦一点的只是在选择具有相同优先级的实时进程时，要考虑两种调度策略。

普通进程的调度

实时进程调度的中心思想是，让处于可执行状态的最高优先级的实时进程尽可能地占有CPU，因为它有实时需求;而普通进程则被认为是没有实时需求的进程，于是调度程序力图让各个处于可执行状态的普通进程和平共处地分享CPU，从而让用户觉得这些进程是同时运行的。

与实时进程相比，普通进程的调度要复杂得多。内核需要考虑两件麻烦事：

一、动态调整进程的优先级

按进程的行为特征，可以将进程分为“交互式进程”和“批处理进程”：

交互式进程(如桌面程序、服务器、等)主要的任务是与外界交互。这样的进程应该具有较高的优先级，它们总是睡眠等待外界的输入。而在输入到来，内核将其唤醒时，它们又应该很快被调度执行，以做出响应。比如一个桌面程序，如果鼠标点击后半秒种还没反应，用户就会感觉系统“卡”了;

批处理进程(如编译程序)主要的任务是做持续的运算，因而它们会持续处于可执行状态。这样的进程一般不需要高优先级，比如编译程序多运行了几秒种，用户多半不会太在意;

如果用户能够明确知道进程应该有怎样的优先级，可以通过nice、setpriority系统调用来对优先级进行设置。(如果要提高进程的优先级，要求用户进程具有CAP_SYS_NICE能力。)

然而应用程序未必就像桌面程序、编译程序这样典型。程序的行为可能五花八门，可能一会儿像交互式进程，一会儿又像批处理进程。以致于用户难以给它设置一个合适的优先级。

再者，即使用户明确知道一个进程是交互式还是批处理，也多半碍于权限或因为偷懒而不去设置进程的优先级。(你又是否为某个程序设置过优先级呢?)

于是，最终，区分交互式进程和批处理进程的重任就落到了内核的调度程序上。

调度程序关注进程近一段时间内的表现(主要是检查其睡眠时间和运行时间)，根据一些经验性的公式，判断它现在是交互式的还是批处理的?程度如何?最后决定给它的优先级做一定的调整。

进程的优先级被动态调整后，就出现了两个优先级：

1、用户程序设置的优先级(如果未设置，则使用默认值)，称为静态优先级。这是进程优先级的基准，在进程执行的过程中往往是不改变的;

2、优先级动态调整后，实际生效的优先级。这个值是可能时时刻刻都在变化的;

二、调度的公平性

在支持多进程的系统中，理想情况下，各个进程应该是根据其优先级公平地占有CPU。而不会出现“谁运气好谁占得多”这样的不可控的情况。

linux实现公平调度基本上是两种思路：

1、给处于可执行状态的进程分配时间片(按照优先级)，用完时间片的进程被放到“过期队列”中。等可执行状态的进程都过期了，再重新分配时间片;

2、动态调整进程的优先级。随着进程在CPU上运行，其优先级被不断调低，以便其他优先级较低的进程得到运行机会;

后一种方式有更小的调度粒度，并且将“公平性”与“动态调整优先级”两件事情合而为一，大大简化了内核调度程序的代码。因此，这种方式也成为内核调度程序的新宠。

强调一下，以上两点都是仅针对普通进程的。而对于实时进程，内核既不能自作多情地去动态调整优先级，也没有什么公平性可言。

普通进程具体的调度算法非常复杂，并且随linux内核版本的演变也在不断更替(不仅仅是简单的调整)，所以本文就不继续深入了。

调度程序的效率

“优先级”明确了哪个进程应该被调度执行，而调度程序还必须要关心效率问题。调度程序跟内核中的很多过程一样会频繁被执行，如果效率不济就会浪费很多CPU时间，导致系统性能下降。

在linux 2.4时，可执行状态的进程被挂在一个链表中。每次调度，调度程序需要扫描整个链表，以找出最优的那个进程来运行。复杂度为O(n);

在linux 2.6早期，可执行状态的进程被挂在N(N=140)个链表中，每一个链表代表一个优先级，系统中支持多少个优先级就有多少个链表。每次调度，调度程序只需要从第一个不为空的链表中取出位于链表头的进程即可。这样就大大提高了调度程序的效率，复杂度为O(1);

在linux 2.6近期的版本中，可执行状态的进程按照优先级顺序被挂在一个红黑树(可以想象成平衡二叉树)中。每次调度，调度程序需要从树中找出优先级最高的进程。复杂度为O(logN)。

那么，为什么从linux 2.6早期到近期linux 2.6版本，调度程序选择进程时的复杂度反而增加了呢?

这是因为，与此同时，调度程序对公平性的实现从上面提到的第一种思路改变为第二种思路(通过动态调整优先级实现)。而O(1)的算法是基于一组数目不大的链表来实现的，按我的理解，这使得优先级的取值范围很小(区分度很低)，不能满足公平性的需求。而使用红黑树则对优先级的取值没有限制(可以用32位、64位、或更多位来表示优先级的值)，并且O(logN)的复杂度也还是很高效的。

调度触发的时机

调度的触发主要有如下几种情况：

1、当前进程(正在CPU上运行的进程)状态变为非可执行状态。

进程执行系统调用主动变为非可执行状态。比如执行nanosleep进入睡眠、执行exit退出、等等;

进程请求的资源得不到满足而被迫进入睡眠状态。比如执行read系统调用时，磁盘高速缓存里没有所需要的数据，从而睡眠等待磁盘IO;

进程响应信号而变为非可执行状态。比如响应SIGSTOP进入暂停状态、响应SIGKILL退出、等等;

2、抢占。进程运行时，非预期地被剥夺CPU的使用权。这又分两种情况：进程用完了时间片、或出现了优先级更高的进程。

优先级更高的进程受正在CPU上运行的进程的影响而被唤醒。如发送信号主动唤醒，或因为释放互斥对象(如释放锁)而被唤醒;

内核在响应时钟中断的过程中，发现当前进程的时间片用完;

内核在响应中断的过程中，发现优先级更高的进程所等待的外部资源的变为可用，从而将其唤醒。比如CPU收到网卡中断，内核处理该中断，发现某个socket可读，于是唤醒正在等待读这个socket的进程;再比如内核在处理时钟中断的过程中，触发了定时器，从而唤醒对应的正在nanosleep系统调用中睡眠的进程。

所有任务都采用linux分时调度策略时：

1，创建任务指定采用分时调度策略，并指定优先级nice值(-20~19)。

2，将根据每个任务的nice值确定在cpu上的执行时间(counter)。

3，如果没有等待资源，则将该任务加入到就绪队列中。

4，调度程序遍历就绪队列中的任务，通过对每个任务动态优先级的计算权值(counter+20-nice)结果，选择计算结果最大的一个去运行，当这个时间片用完后(counter减至0)或者主动放弃cpu时，该任务将被放在就绪队列末尾(时间片用完)或等待队列(因等待资源而放弃cpu)中。

5，此时调度程序重复上面计算过程，转到第4步。

6，当调度程序发现所有就绪任务计算所得的权值都为不大于0时，重复第2步。

所有任务都采用FIFO时：

1，创建进程时指定采用FIFO，并设置实时优先级rt_priority(1-99)。

2，如果没有等待资源，则将该任务加入到就绪队列中。

3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu，该FIFO任务将一直占有cpu直到有优先级更高的任务就绪(即使优先级相同也不行)或者主动放弃(等待资源)。

4，调度程序发现有优先级更高的任务到达(高优先级任务可能被中断或定时器任务唤醒，再或被当前运行的任务唤醒，等等)，则调度程序立即在当前任务堆栈中保存当前cpu寄存器的所有数据，重新从高优先级任务的堆栈中加载寄存器数据到cpu，此时高优先级的任务开始运行。重复第3步。

5，如果当前任务因等待资源而主动放弃cpu使用权，则该任务将从就绪队列中删除，加入等待队列，此时重复第3步。

所有任务都采用RR调度策略时：

1，创建任务时指定调度参数为RR，并设置任务的实时优先级和nice值(nice值将会转换为该任务的时间片的长度)。

2，如果没有等待资源，则将该任务加入到就绪队列中。

3，调度程序遍历就绪队列，根据实时优先级计算调度权值(1000+rt_priority),选择权值最高的任务使用cpu。

4，如果就绪队列中的RR任务时间片为0，则会根据nice值设置该任务的时间片，同时将该任务放入就绪队列的末尾。重复步骤3。

5，当前任务由于等待资源而主动退出cpu，则其加入等待队列中。重复步骤3。

系统中既有分时调度，又有时间片轮转调度和先进先出调度：

1，RR调度和FIFO调度的进程属于实时进程，以分时调度的进程是非实时进程。

2，当实时进程准备就绪后，如果当前cpu正在运行非实时进程，则实时进程立即抢占非实时进程。

3，RR进程和FIFO进程都采用实时优先级做为调度的权值标准，RR是FIFO的一个延伸。FIFO时，如果两个进程的优先级一样，则这两个优先级一样的进程具体执行哪一个是由其在队列中的未知决定的，这样导致一些不公正性(优先级是一样的，为什么要让你一直运行?),如果将两个优先级一样的任务的调度策略都设为RR,则保证了这两个任务可以循环执行，保证了公平。

Ingo Molnar-实时补丁

为了能并入主流内核，Ingo Molnar的实时补丁也采用了非常灵活的策略，它支持四种抢占模式：

1.No Forced Preemption(Server)，这种模式等同于没有使能抢占选项的标准内核，主要适用于科学计算等服务器环境。

2.Voluntary Kernel Preemption(Desktop)，这种模式使能了自愿抢占，但仍然失效抢占内核选项，它通过增加抢占点缩减了抢占延迟，因此适用于一些需要较好的响应性的环境，如桌面环境，当然这种好的响应性是以牺牲一些吞吐率为代价的。

3.Preemptible Kernel(Low-Latency Desktop)，这种模式既包含了自愿抢占，又使能了可抢占内核选项，因此有很好的响应延迟，实际上在一定程度上已经达到了软实时性。它主要适用于桌面和一些嵌入式系统，但是吞吐率比模式2更低。

4.Complete Preemption(Real-Time)，这种模式使能了所有实时功能，因此完全能够满足软实时需求，它适用于延迟要求为100微秒或稍低的实时系统。

实现实时是以牺牲系统的吞吐率为代价的，因此实时性越好，系统吞吐率就越低。