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 freed. 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, "cant 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 本身的特征, 举例: 多线程就考虑多个执行流同时执行, 别瞎想什么调度啊, 内核态用户态什么哒~
来源: http://blog.csdn.net/lovestackover/article/details/79301501