Big Kernel Lock(BKL)(大内核锁),是linux内核中使用到的一种锁,它跟普通的锁原理上的一样的:
lock_kernel();
/* 临界区 */
unlock_kernel();
但是它又有一些非常诡异的地方。从表面上看:
1、BKL是一个全局的锁(注意,是“一个”而不是“一种”),它保护所有使用它来同步的临界区。一旦一个进程获得BKL,进入被它保护的临界区,不但该临界区被上锁,所有被它保护的临界区都一起被锁住。
这看起来非常之武断:进程A在CPU_1上操作链表list_a,而进程B在CPU_2上操作全局变量var_b,这两者本身毫无瓜葛。但如果你使用了BKL,它们就要“被同步”。
2、BKL是递归锁。同一进程中可以对BKL嵌套的上锁和解锁,当解锁次数等于上锁次数时,锁才真正被释放。
这一点虽然跟内核中的其他锁不大一样,但倒也不算神奇,用户态的pthread_mutex也支持这样的递归锁。
3、BKL有自动释放的特性。(这是在进程主动执行 schedule() 进程切换时)在CPU_N上,如果当前进程A持有BKL,则当CPU_N上面发生调度时,进程A持有的BKL将被自动释放。而当进程A再次被调度执行时,它又自动获得BKL(如果BKL正在被其他进程持有,则进程A不会被调度执行)。
这个特性对于普通的用户态程序来说实在是不可思议:进程A进入了临界区,要准备修改某全局链表list_a,但是由于某种原因而进入睡眠(比如系统内存紧缺时,等待分配内存),结果锁就被自动释放了。而另一个进程B就可以堂而皇之的获得锁而进入临界区,并且把全局链表list_a给改了。等进程A从睡眠中被唤醒的时候,再重新获得大内核锁。
lock_kernel();
/* 临界区 */
unlock_kernel();
但是它又有一些非常诡异的地方。从表面上看:
1、BKL是一个全局的锁(注意,是“一个”而不是“一种”),它保护所有使用它来同步的临界区。一旦一个进程获得BKL,进入被它保护的临界区,不但该临界区被上锁,所有被它保护的临界区都一起被锁住。
这看起来非常之武断:进程A在CPU_1上操作链表list_a,而进程B在CPU_2上操作全局变量var_b,这两者本身毫无瓜葛。但如果你使用了BKL,它们就要“被同步”。
2、BKL是递归锁。同一进程中可以对BKL嵌套的上锁和解锁,当解锁次数等于上锁次数时,锁才真正被释放。
这一点虽然跟内核中的其他锁不大一样,但倒也不算神奇,用户态的pthread_mutex也支持这样的递归锁。
3、BKL有自动释放的特性。(这是在进程主动执行 schedule() 进程切换时)在CPU_N上,如果当前进程A持有BKL,则当CPU_N上面发生调度时,进程A持有的BKL将被自动释放。而当进程A再次被调度执行时,它又自动获得BKL(如果BKL正在被其他进程持有,则进程A不会被调度执行)。
这个特性对于普通的用户态程序来说实在是不可思议:进程A进入了临界区,要准备修改某全局链表list_a,但是由于某种原因而进入睡眠(比如系统内存紧缺时,等待分配内存),结果锁就被自动释放了。而另一个进程B就可以堂而皇之的获得锁而进入临界区,并且把全局链表list_a给改了。等进程A从睡眠中被唤醒的时候,再重新获得大内核锁。