1. 写在之前
在阅读本文前,如果下面的问题您都能回答出来,那么本文你可以从略。
Pthread_spin_lock
和Spin_lock
的区别?Spin_lock
对于单核非抢占内核,为何是无意义的?- 那么中断处理函数的执行是在内核态或者用户态呢?
如果上面3个问题,您都能回答出来,说明本文所讲述的内容,您大体上都了解了。本文基于Pthread_spin_lock
探究下其用法及进行相关的实验。
2. 基本概念
首先不要搅浑任务调度和内核抢占,两个概念是指着不同的角度说的。内核抢占是对于处于内核态的进程是否能被调度的描述,而任务调度是指进程处于用户态时发生的调度。那么对于非抢占内核和抢占内核,在用户态的调度是没有区别的,但是在内核态对待调度行为的差别区分了抢占内核和非抢占内核。以下描述取自 《ULK 3th 》:
in nonpreemptive kernels, the current process cannot be replaced unless it is about to switch to User Mode.
以下内容摘自维基百科:
Kernel preemption is a method used mainly in monolithic and hybrid kernels where all or most device drivers are run in kernel space, whereby the scheduler is permitted to forcibly perform a context switch (i.e. preemptively schedule; on behalf of a runnable and higher priority process) on a driver or other part of the kernel during its execution, rather than co-operatively waiting for the driver or kernel function (such as a system call) to complete its execution and return control of the processor to the scheduler.
本文不打算介绍内核调度机制,但是基本的概念要明白:在内核可抢占的系统中,调度可以发生在内核态的执行过程,换句话说,对于非抢占的系统中,调度只能等内核态的执行流执行完,不要混淆调度算法中每个进程时间片耗尽时任务调度,对于非抢占和抢占内核,在用户态的切换应该是没有区别的。区别只发生在一种场景:在内核态的任务调度的处理方式!
回过头来思考第一个问题:Pthread_spin_lock
和Spin_lock
的区别? 答案应该是即相互区别又相互联系,前者用在用户态的编程,后者用在内核态的编程。如果进行应用程序的开发,那么前者是我们的实现spin_lock
的手段。但当我们进行驱动编程或者内核态进程编程时,后者就是我们实现spin_lock
的手段。
第二个问题:Spin_lock
对于单核非抢占内核,为何是无意义的?
以下资料来自quora, 该回答太棒了,因为比较多,笔者节选了其中部分。
Time Sliced Scheduling: In this scenario what happens is, Process A acquires the spin lock for resource X and then having exhausted its time slice is swapped for Process B. The Process B attempts to acquire the spin lock and starts busy-waiting for the lock to be free’d. After a while, it completes its time slice and is Process A is swapped back on the CPU and continues processing. This cycle repeats until process A completes its task and releases the lock at which point Process B can now acquire the lock and start working. Do you see how wasteful this scenario was?
如果您不想看英文,那么看看我的总结:有人会说,在单核中会发生deadlock,这不准确。取决于使用何种调度算法,还有使用的spin_lock发生内核态还是用户态,如果使用CFS调度算法及在用户态进行spin_lock
,此时会严重降低系统性能。有些调度算法比如EDF,则会造成dead_lock。
那么上面还是没有提到抢占非抢占的概念,如果我们使用spin_lock在内核态,比如在驱动编写中Spin_lock如果针对的是非抢占的内核,而系统又是单核的话,这就是灾难!
第三个问题:那么中断处理函数的执行实在内核态或者用户态呢? 这个答案是百分之百在内核态,并且在处理完中断返回的时候,如果被中断的时候进程处于用户态,则中断处理函数返回的时候会发生一次调度。
3. 主要API
#include <pthread.h>
int pthread_spin_init(pthread_spinlock_t *lock, int pshared);
int pthread_spin_destroy(pthread_spinlock_t *lock);
Both return: 0 if OK, error number on failure
int pthread_spin_lock(pthread_spinlock_t *lock);
int pthread_spin_trylock(pthread_spinlock_t *lock);
int pthread_spin_unlock(pthread_spinlock_t *lock);
All return: 0 if OK, error number on failure
简单阐述下pthread_spin_lock
的用法:
pthread_spin_init
初始化一个锁,pthread_spin_lock
当前线程加锁,如果未获得锁,将一直忙等待,此时该线程上的cpu一直处于忙等待。- 如果调度算法为CFS,那么spin_lock可能会降低系统性能。只有靠我们自己评估context switch和spin_lock的代价大小了。
NOTE: 以上步骤假设使用SMP架构处理器
4. 实验
如果我们简单的将我们上一篇使用的Mutex
替换为spin_lock
,看看会发生什么?
4.1 测试一:
[root@localhost ~]# diff -Naur 11_4.c 11_6.c
--- 11_4.c 2018-02-09 17:48:17.463201599 +0800
+++ 11_6.c 2018-02-09 20:09:33.666472377 +0800
@@ -13,7 +13,7 @@
};
struct foo *fh[NHASH];
-pthread_mutex_t hashlock = PTHREAD_MUTEX_INITIALIZER;
+pthread_spinlock_t spin;
pthread_mutex_t hashr_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t hashr_cond = PTHREAD_COND_INITIALIZER;
@@ -28,12 +28,12 @@
if ((fp = malloc(sizeof(struct foo))) != NULL)
{
fp->f_id = id;
- foo_printf(fp);
idx = HASH(id);
- pthread_mutex_lock(&hashlock);
+ pthread_spin_lock(&spin);
fp->f_next = fh[idx];
fh[idx] = fp;
- pthread_mutex_unlock(&hashlock);
+ foo_printf(fp);
+ pthread_spin_unlock(&spin);
}
return(fp);
}
@@ -41,7 +41,7 @@
struct foo * foo_find(int id)
{
struct foo * fp;
- pthread_mutex_lock(&hashlock);
+ pthread_spin_lock(&spin);
for (fp = fh[HASH(id)]; fp != NULL; fp = fp->f_next)
{
if (fp->f_id == id)
@@ -49,7 +49,7 @@
break;
}
}
- pthread_mutex_unlock(&hashlock);
+ pthread_spin_unlock(&spin);
return(fp);
}
@@ -57,18 +57,18 @@
{
struct foo * fp;
struct foo * fp1;
- pthread_mutex_lock(&hashlock);
+ pthread_spin_lock(&spin);
for (fp = fh[HASH(id)]; fp != NULL; fp = fp->f_next)
{
if (fp->f_id == id)
{
- if( fp == fh[HASH(id)])
+ if(fp == fh[HASH(id)])
{
fh[HASH(id)] = fp->f_next;
}
else
{
- fp1=fh[HASH(id)];
+ fp1=fh[HASH(id)];
while (fp1->f_next != fp)
fp1 = fp1->f_next;
fp1->f_next = fp->f_next;
@@ -76,7 +76,7 @@
break;
}
}
- pthread_mutex_unlock(&hashlock);
+ pthread_spin_unlock(&spin);
if(fp == NULL)
return 1;
free(fp);
@@ -124,8 +124,9 @@
int done[3]={4,4,4};
pthread_t tid;
char i=0;
+ pthread_spin_init(&spin,PTHREAD_PROCESS_PRIVATE);
for( num=0;num<NHASH;num++)
- {
+ {
err = pthread_create(&tid, NULL, thr_fn,(void *)(num*NHASH));
if (err != 0)
errx(1, "can’t create thread:%d\n",num);
结果如下:
[root@localhost ~]# ./11_6
thread 140351228299008, foo_id:0
thread 140351219906304, foo_id:3
thread 140351236589312, foo_id:0
thread 140351142622976, foo_id:6
thread 140351236589312, foo_id:3
thread 140351236589312, foo_id:6
正常完成了测试,发现竟然简单的替换就成功了。但是需要进行下简单的时间测试,增加测试时间的代码(为了篇幅,不贴出来)并与上个使用mutex
的实验对比,结果如下:
//spin_lock版本
[root@localhost ~]# ./11_6_1
thread 140228922906368, foo_id:0
thread 140228914513664, foo_id:3
thread 140228931196672, foo_id:0
thread 140228906120960, foo_id:6
thread 140228931196672, foo_id:3
thread 140228931196672, foo_id:6
run time:3769
//mutex版本
[root@localhost ~]# ./11_6_2
thread 140255847200512, foo_id:0
thread 140255830415104, foo_id:6
thread 140255838807808, foo_id:3
thread 140255855490816, foo_id:0
thread 140255855490816, foo_id:3
thread 140255855490816, foo_id:6
run time:2139
Spin_lock
版本比mutex
版本运行的时间还要长,也就是说spin_lock
不适合在这样的场合!比较笼统的解释这样的结果就是spin_lock
自身进行忙等待的消耗大于了mutex
所引发的线程调度的上下文切换的开销,说白了就是spin所保护的代码段所进行的操作比较长。
4.2 测试二:
[root@localhost ~]# diff -Naur 11_6.c 11_6_3.c
--- 11_6.c 2018-02-09 20:09:33.666472377 +0800
+++ 11_6_3.c 2018-02-09 20:12:12.235815697 +0800
@@ -33,7 +33,7 @@
fp->f_next = fh[idx];
fh[idx] = fp;
foo_printf(fp);
- pthread_spin_unlock(&spin);
+ // pthread_spin_unlock(&spin); 刻意不释放锁
}
return(fp);
}
结果:
[root@localhost ~]# ./11_6_3
thread 139762245465856, foo_id:0
//程序卡死在这里
3个核心deadlock,因为有一个线程调用了foo_alloc
,首先获得了锁,然后又会调用pthread_cond_wait
从而自己sleep了。此时其他的两个线程就会deadlock,然而主线程当其调用foo_find
时也会deadlock。所以top
命令的结果如上所示。同时从侧面我们也发现Linux任务调度的单位是线程,在Linux线程本质上作为进程处理,更具体详细的信息需要看相关内核调度的知识了。
5. 留在最后
接触了spin_lock
,笔者才发现自己的内功太浅
,以后会再把内核相关的书好好看看,因为有些问题是基本功!笔者注意到驱动编程和在应用层编程区别有些明显啊,在使用POSIX接口API进行编程的时候,不应该考虑到内核层面,所以我得出一个结论:进行POSIX编程时,忽略内核层面特征,只考虑API本身的特征,举例:多线程就考虑多个执行流同时执行,别瞎想什么调度啊,内核态用户态什么哒~