收藏 分享(赏)

内核中断,异常,抢占总结篇.doc

上传人:kpmy5893 文档编号:6003973 上传时间:2019-03-23 格式:DOC 页数:16 大小:95.50KB
下载 相关 举报
内核中断,异常,抢占总结篇.doc_第1页
第1页 / 共16页
内核中断,异常,抢占总结篇.doc_第2页
第2页 / 共16页
内核中断,异常,抢占总结篇.doc_第3页
第3页 / 共16页
内核中断,异常,抢占总结篇.doc_第4页
第4页 / 共16页
内核中断,异常,抢占总结篇.doc_第5页
第5页 / 共16页
点击查看更多>>
资源描述

1、内核中断,异常,抢占总结篇一、基本概念中断分为同步中断和异步中断。同步中断是由 CPU 控制单元产生的,“ 同步”是指只有在一条指令执行完毕后,CPU 才会发出中断,而不是发生在代码指令执行期间,比如系统调用。而异步中断是由其他硬件设备依照 CPU 时钟信号产生的,即意味着中断能够在指令之间发生,例如键盘中断。按照 Intel 的微处理器手册,同步中断和异步中断也分别称为异常(或者软件中断)和中断。中断大家都比较熟悉,是由硬件设备产生的。异常的产生源有两种:一种是由程序的错误产生的,内核通过发送一个 Unix 程序员都熟悉的信号来处理异常;第二种时内核必须处理的异常条件产生的,此时内核执行恢复

2、异常需要的所有步骤,例如缺页,或对内核服务的一个请求(系统调用,通过一条 int 指令)。有一个知识点值得了解:内核态能够触发的唯一异常就是缺页异常,其他的都是用户态触发的。二、硬中断、软中断、异常之间的抢占关系硬中断可以被另一个优先级比自己高的硬中断“中断” ,不能被 同级(同一种硬中断)或低级的硬中断“中断”,更不能被软中断“中断” 。软中断可以被硬中断“中断”,但是不会被另一个软中断“中断”。在一个 CPU 上,软中断总是串行执行。所以在单处理器上,对软中断的数据结构进行访问不需要加任何同步原语。(关于这一点,我对深入理解 linux 内核第三版 P223 页中保护可延迟函数所访问的数据

3、结构有疑问,书上说保护可延迟函数(软中断)所访问的数据结构应采取的措施:对于单处理器的情况,在单处理器上不存在竞争条件,这是因为可延迟函数(软中断)的执行总是在一个 CPU 上串行执行-也就是说,一个可延迟函数不会被另一个可延迟函数中断。因此,根本不需要同步原语。我认为:一个软中断虽然不会被另一个软中断“中断”,但是可能被硬中断“中断” ,而硬中断最后还是要执行到软中断,因此还是会形成对资源的临界区访问。我觉得在保护软中断时,应该关闭本地软中断,比如用 local_bh_disable)还没写完这篇博客,就知道我在这个问题上错了。附上在 Linux 内核开发中文邮件列表上某位仁兄提供的解答。开

4、始处理软中断的情况主要是1、中断退出执行的 irq_exit2、内核线程 ksoftirqd3、local_bh_enable而asmlinkage void do_softirq(void)unsigned long flags;struct thread_info *curctx;union irq_ctx *irqctx;u32 *isp;if (in_interrupt()return;可以看到,in_interrupt 判断,当前若是从硬件中断退出后执行的 irq_exit 进入的do_softirq,则立即返回,可以避免你说的情况本文最后还将附上一篇软中断源码的分析,很详细地说明了

5、这个问题。硬中断和软中断都可以抢占(或者称为中断)异常(最典型的是系统调用),但是异常不能抢占硬中断和软中断。硬中断和软中断(只要是中断上下文)执行的时候都不允许内核抢占,换句话说,中断上下文中永远不允许进程切换。(个人理解,由于中断处理程序都需要较快地完成,而且中断处理程序可以嵌套,因此中断处理程序必须不能阻塞,否则性能就非常不能保证了。)三、用户抢占和内核抢占抢占分两种情况:用户抢占和内核抢占,其中内核抢占在 Linux2.5.4 版本发布时被并入内核的,通 SMP 一样作为内核的一项标准可选配置。1、用户抢占:内核即将返回用户空间的时候,如果 need resched 标志被设置,会导致

6、schedule()被调用,此时就会发生用户抢占。在内核返回用户空间的时候,它知道自己是安全的。所以,内核无论是在从中断处理程序还是在系统调用后返回,都会检查 need resched 标志。如果它被设置了,那么,内核会选择一个其他( 更合适的)进程投入运行。在内核抢占还没有出现的时候,内核所有的抢占情况都是用户抢占。2、内核抢占:内核抢占是指,一个在内核态运行的进程,可能在执行内核函数期间被另一个进程取代。不是在内核的任何一个地方都可以发生内核抢占的。内核不能被抢占的情况如下:1)内核正进行中断处理。在 Linux 内核中进程不能抢占中断 (中断只能被其他中断中止、抢占,进程不能中止、抢占中

7、断),在中断例程中不允许进行进程调度。进程调度函数schedule()会对此作出判断,如果是在中断中调用,会打印出错信息。2)内核正在进行中断上下文的 Bottom Half(中断的底半部)处理。硬件中断返回前会执行软中断,此时仍然处于中断上下文中。3)内核的代码段正持有 spinlock 自旋锁、writelock/readlock 读写锁等锁,处干这些锁的保护状态中。内核中的这些锁是为了在 SMP 系统中短时间内保证不同 CPU 上运行的进程并发执行的正确性。当持有这些锁时,内核不应该被抢占。4)内核正在执行调度程序 Scheduler。抢占的原因就是为了进行新的调度,没有理由将调度程序抢

8、占掉再运行调度程序。5)内核正在对每个 CPU“私有” 的数据结构操作(Per-CPU date structures)。在 SMP 中,对于 per-CPU 数据结构未用 spinlocks 保护,因为这些数据结构隐含地被保护了(不同的CPU 有不一样的 per-CPU 数据,其他 CPU 上运行的进程不会用到另一个 CPU 的 per-CPU 数据)。但是如果允许抢占,但一个进程被抢占后重新调度,有可能调度到其他的CPU 上去,这时定义的 Per-CPU 变量就会有问题,这时应禁抢占。除了上述情况,在内核的任何地方都可能发生内核抢占,内核抢占发生的时机一般在:1)当从中断处理程序正在执行,

9、且返回内核空间之前。2)当内核代码再一次具有可抢占性的时候,如解锁(spin_unlock_bh)及使能软中断(local_bh_enable)等。3)如果内核中的任务显式的调用 schedule()。4)如果内核中的任务阻塞(这同样也会导致调用 schedule()。内核抢占主要是为实时系统来设计的,但也不是在所有情况下都是最优的,因为抢占也需要调度和同步开销,在某些情况下甚至要关闭内核抢占。以下是一篇关于开启和关闭内核抢占性能测试的文章。http:/ CPU 变量的情况下,必须显式地禁用内核抢占,其他情况下内核抢占不会出现问题。2、保护中断所访问的数据结构1)单处理器情况下:假如数据结构只

10、被这一种中断访问,则完全可以不加同步原语,因为中断不能被同一种中断“中断 ”;假如数据结构被多个中断处理程序访问,则必须通过禁用本地中断来保护临界区。2)多处理器情况下:除了必须禁用本地中断,还必须使用自旋锁来避免来自其他 CPU 的干扰。可以使用如 spin_lock_irq()来完成这两件事情。3、保护可延迟函数(软中断和 tasklet)所访问的数据结构1)单处理器情况下:在单处理器系统上不存在竞争条件,因为可延迟函数的执行在一个CPU 上是串行的,一个可延迟函数不会被另一个可延迟函数所中断。因此无需同步原语。2)多处理器情况下:需要自旋锁来加以保护。由于软中断和 tasklet 并发程

11、度不同,加锁情况也不同。同一软中断可以在不同 CPU 上运行,因此无论一个或多个软中断,都必须用如 spin_lock 加以保护。同一 tasklet 不能在不同 CPU 上运行,因此无需加锁;不同tasklet 可以在不同 CPU 上运行,因此也需要如 spin_lock 的锁加以保护。4、保护由异常和中断访问的数据结构单处理器情况下:1)对中断而言:中断不能被异常“ 中断”,无需考虑异常的干扰。第 1 条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。2)对异常而言:异常的优先级低,如需访问共享数据结构,必须先禁用本地中断。多处理器情况下:1)对中断而言:除了单

12、处理器考虑的情况外,还必须用自旋锁排除其他 CPU 的干扰。2)对异常而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他 CPU 的干扰。5、保护由异常和可延迟函数访问的数据结构单处理器情况下:1)对可延迟函数而言:可延迟函数不能被异常“ 中断”,无需考虑异常的干扰。在每个CPU 上可延迟函数串行执行,不存在竞争条件,因此不用同步原语。2)对异常而言:异常的优先级低,如需访问共享数据结构,必须先禁用本地软中断。多处理器情况下:1)对中断而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他 CPU 的干扰。2)对异常而言:除了单处理器考虑的情况外,还必须用自旋锁排除其他 CPU 的干扰。6

13、、保护由中断和可延迟函数访问的数据机构 单处理器情况下:1)对中断而言:中断不能被可延迟函数“ 中断”,无需考虑可延迟函数的干扰。第 1 条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。2)对可延迟函数而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。多处理器情况下:1)对中断而言:除了单处理器上考虑的外,还必须用自旋锁排除其他 CPU 的干扰。2)对可延迟函数而言:除了单处理器上考虑的外,还必须用自旋锁排除其他 CPU 的干扰。7、保护由异常、中断和可延迟函数访问的数据结构单处理器情况下:1)对中断而言:优先级最高,无需考虑其他两种的影响。第

14、 1 条一样,如果此数据结构只被一种中断访问,则可不加同步原语;否则要禁用本地中断。2)对可延迟函数而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。3)对异常而言:可延迟函数的优先级低,如需访问共享数据结构,必须先禁用本地中断。禁用了本地中断,也就相当于禁用了本地软中断。多处理器情况下:1)对中断而言:除了单处理器上考虑的外,还必须用自旋锁排除其他 CPU 的干扰。2)对可延迟函数而言:除了单处理器上考虑的外,还必须用自旋锁排除其他 CPU 的干扰。3)对异常而言:除了单处理器上考虑的外,还必须用自旋锁排除其他 CPU 的干扰。 五、软中断源码分析之所以说软中断的执行时是

15、串行的,是因为在软中断执行时,对于从硬中断进来的即将要执行的新的软中断会采取屏蔽措施,不让他们立即运行,而是保存起来,延迟一会,等自身的软中断执行完毕后,再执行那些保存起来的软中断,从而达到串行的目的。cpp view plaincopyprint?1./ 2./ do_IRQ 函数执行完硬件 ISR 后退出时调用此函数。 3./ 4.void irq_exit(void) 5. 6. account_system_vtime(current); 7. trace_hardirq_exit(); 8. sub_preempt_count(IRQ_EXIT_OFFSET); 9. / 10. /

16、 判断当前是否有硬件中断嵌套,并且是否有软中断在 11. / pending 状态,注意:这里只有两个条件同时满足 12. / 时,才有可能调用 do_softirq() 进入软中断。也就是 13. / 说确认当前所有硬件中断处理完成,且有硬件中断安装了 14. / 软中断处理时理时才会进入。 15. / 16. if (!in_interrupt() 21. preempt_enable_no_resched(); 22. 23.#ifndef _ARCH_HAS_DO_SOFTIRQ 24.asmlinkage void do_softirq(void) 25. 26. _u32 pend

17、ing; 27. unsigned long flags; 28. / 29. / 这个函数判断,如果当前有硬件中断嵌套,或 30. / 有软中断正在执行时候,则马上返回。在这个 31. / 入口判断主要是为了和 ksoftirqd 互斥。 32. / 33. if (in_interrupt() 34. return; 35. / 36. / 关中断执行以下代码 37. / 38. local_irq_save(flags); 39. / 40. / 判断是否有 pending 的软中断需要处理。 41. / 42. pending = local_softirq_pending(); 43

18、. / 44. / 如果有则调用 _do_softirq() 进行实际处理 45. / 46. if (pending) 47. _do_softirq(); 48. / 49. / 开中断继续执行 50. / 51. local_irq_restore(flags); 52. 53./ 54./ 最大软中断调用次数为 10 次。 55./ 56.#define MAX_SOFTIRQ_RESTART 10 57.asmlinkage void _do_softirq(void) 58. 59. / 60. / 软件中断处理结构,此结构中包括了 ISR 中 61. / 注册的回调函数。 62.

19、 / 63. struct softirq_action *h; 64. _u32 pending; 65. int max_restart = MAX_SOFTIRQ_RESTART; 66. int cpu; 67. / 68. / 得到当前所有 pending 的软中断。 69. / 70. pending = local_softirq_pending(); 71. account_system_vtime(current); 72. / 73. / 执行到这里要屏蔽其他软中断,这里也就证实了 74. / 每个 CPU 上同时运行的软中断只能有一个。 75. / 76. _local_

20、bh_disable(unsigned long)_builtin_return_address(0); 77. trace_softirq_enter(); 78. / 79. / 针对 SMP 得到当前正在处理的 CPU 80. / 81. cpu = smp_processor_id(); 82./ 83./ 循环标志 84./ 85.restart: 86. / 87. / 每次循环在允许硬件 ISR 强占前,首先重置软中断 88. / 的标志位。 89. / 90. /* Reset the pending bitmask before enabling irqs */ 91. se

21、t_softirq_pending(0); 92. / 93. / 到这里才开中断运行,注意:以前运行状态一直是关中断 94. / 运行,这时当前处理软中断才可能被硬件中断抢占。也就 95. / 是说在进入软中断时不是一开始就会被硬件中断抢占。只有 96. / 在这里以后的代码才可能被硬件中断抢占。 97. / 98. local_irq_enable(); 99. / 100. / 这里要注意,以下代码运行时能被硬件中断抢占,但 101. / 这个硬件 ISR 执行完成后,他的所注册的软中断无法马上运行, 102. / 别忘了,目前虽是开硬件中断执行,但前面的_local_bh_disabl

22、e() 103. / 函数屏蔽了软中断。所以这种环境下只能被硬件中断抢占,但这 104. / 个硬中断注册的软中断回调函数无法运行。要问为什么,那是因为 105. / _local_bh_disable() 函数设置了一个标志当作互斥量,而这个 106. / 标志正是上面的 irq_exit() 和 do_softirq() 函数中的 107. / in_interrupt() 函数判断的条件之一,也就是说in_interrupt() 108. / 函数不仅检测硬中断而且还判断了软中断。所以在这个环境下触发 109. / 硬中断时注册的软中断,根本无法重新进入到这个函数中来,只能 110. /

23、 是做一个标志,等待下面的重复循环(最大MAX_SOFTIRQ_RESTART) 111. / 才可能处理到这个时候触发的硬件中断所注册的软中断。 112. / 113. / 114. / 得到软中断向量表。 115. / 116. h = softirq_vec; 117. / 118. / 循环处理所有 softirq 软中断注册函数。 119. / 120. do 121. / 122. / 如果对应的软中断设置 pending 标志则表明 123. / 需要进一步处理他所注册的函数。 124. / 125. if (pending 130. rcu_bh_qsctr_inc(cpu);

24、 131. 132. / 133. / 继续找,直到把软中断向量表中所有 pending 的软 134. / 中断处理完成。 135. / 136. h+; 137. / 138. / 从代码里能看出按位操作,表明一次循环只 139. / 处理 32 个软中断的回调函数。 140. / 141. pending = 1; 142. while (pending); 143. / 144. / 关中断执行以下代码。注意:这里又关中断了,下面的 145. / 代码执行过程中硬件中断无法抢占。 146. / 147. local_irq_disable(); 148. / 149. / 前面提到过,

25、在刚才开硬件中断执行环境时只能被硬件中断 150. / 抢占,在这个时候是无法处理软中断的,因为刚才开中 151. / 断执行过程中可能多次被硬件中断抢占,每抢占一次就有可 152. / 能注册一个软中断,所以要再重新取一次所有的软中断。 153. / 以便下面的代码进行处理后跳回到 restart 处重复执行。 154. / 155. pending = local_softirq_pending(); 156. / 157. / 如果在上面的开中断执行环境中触发了硬件中断,且每个都 158. / 注册了一个软中断的话,这个软中断会设置 pending 位, 159. / 但在当前一直屏蔽软

26、中断的环境下无法得到执行,前面提 160. / 到过,因为 irq_exit() 和 do_softirq() 根本无法进入到 161. / 这个处理过程中来。这个在上面周详的记录过了。那么在 162. / 这里又有了一个执行的机会。注意:虽然当前环境一直是 163. / 处于屏蔽软中断执行的环境中,但在这里又给出了一个执行 164. / 刚才在开中断环境过程中触发硬件中断时所注册的软中断的 165. / 机会,其实只要理解了软中断机制就会知道,无非是在一些特 166. / 定环境下调用 ISR 注册到软中断向量表里的函数而已。 167. / 168. / 169. / 如果刚才触发的硬件中断

27、注册了软中断,并且重复执行次数 170. / 没有到 10 次的话,那么则跳转到 restart 标志处重复以上 171. / 所介绍的所有步骤:设置软中断标志位,重新开中断执行. 172. / 注意:这里是要两个条件都满足的情况下才可能重复以上步骤。173. / 174. if (pending 176. / 177. / 如果以上步骤重复了 10 次后更有 pending 的软中断的话, 178. / 那么系统在一定时间内可能达到了一个峰值,为了平衡这点。 179. / 系统专门建立了一个 ksoftirqd 线程来处理,这样避免在一 180. / 定时间内负荷太大。这个 ksoftirq

28、d 线程本身是个大循环, 181. / 在某些条件下为了不负载过重,他是能被其他进程抢占的, 182. / 但注意,他是显示的调用了 preempt_xxx() 和 schedule() 183. / 才会被抢占和转换的。这么做的原因是因为在他一旦调用 184. / local_softirq_pending() 函数检测到有 pending 的软中断 185. / 需要处理的时候,则会显示的调用 do_softirq() 来处理软中 186. / 断。也就是说,下面代码唤醒的 ksoftirqd 线程有可能会回 187. / 到这个函数当中来,尤其是在系统需要响应非常多软中断的情况 188.

29、 / 下,他的调用入口是 do_softirq(),这也就是为什么在do_softirq() 189. / 的入口处也会用 in_interrupt() 函数来判断是否有软中断 190. / 正在处理的原因了,目的还是为了防止重入。ksoftirqd 实现 191. / 看下面对 ksoftirqd() 函数的分析。 192. / 193. if (pending) 194. / 195. / 此函数实际是调用 wake_up_process() 来唤醒ksoftirqd 196. / 197. wakeup_softirqd(); 198. trace_softirq_exit(); 199

30、. account_system_vtime(current); 200. / 201. / 到最后才开软中断执行环境,允许软中断执行。注意:这里 202. / 使用的不是 local_bh_enable(),不会再次触发do_softirq() 203. / 的调用。 204. / 205. _local_bh_enable(); 206. 207. static int ksoftirqd(void * _bind_cpu) 208. 209. / 210. / 显示调用此函数设置当前进程的静态优先级。当然, 211. / 这个优先级会随调度器策略而变化。 212. / 213. set_

31、user_nice(current, 19); 214. / 215. / 设置当前进程不允许被挂启 216. / 217. current-flags |= PF_NOFREEZE; 218. / 219. / 设置当前进程状态为可中断的状态,这种睡眠状 220. / 态可响应信号处理等。 221. / 222. set_current_state(TASK_INTERRUPTIBLE); 223. / 224. / 下面是个大循环,循环判断当前进程是否会停止, 225. / 不会则继续判断当前是否有 pending 的软中断需 226. / 要处理。 227. / 228. while (

32、!kthread_should_stop() 229. / 230. / 如果能进行处理,那么在此处理期间内禁止 231. / 当前进程被抢占。 232. / 233. preempt_disable(); 234. / 235. / 首先判断系统当前没有需要处理的 pending 状态的 236. / 软中断 237. / 238. if (!local_softirq_pending() 239. / 240. / 没有的话在主动放弃 CPU 前先要允许抢占,因为 241. / 一直是在不允许抢占状态下执行的代码。 242. / 243. preempt_enable_no_resched

33、(); 244. / 245. / 显示调用此函数主动放弃 CPU 将当前进程放入睡眠队列, 246. / 并转换新的进程执行(调度器相关不记录在此) 247. / 248. schedule(); 249. / 250. / 注意:如果当前显示调用 schedule() 函数主动转换的进 251. / 程再次被调度执行的话,那么将从调用这个函数的下一条 252. / 语句开始执行。也就是说,在这里当前进程再次被执行的 253. / 话,将会执行下面的 preempt_disable()函数。 254. / 255. / 256. / 当进程再度被调度时,在以下处理期间内禁止当前进程 257.

34、 / 被抢占。 258. / 259. preempt_disable(); 260. 261. / 262. / 设置当前进程为运行状态。注意:已设置了当前进程不可抢占 263. / 在进入循环后,以上两个分支不论走哪个都会执行到这里。一是 264. / 进入循环时就有 pending 的软中断需要执行时。二是进入循环时 265. / 没有 pending 的软中断,当前进程再次被调度获得CPU 时继续 266. / 执行时。 267. / 268. _set_current_state(TASK_RUNNING); 269. / 270. / 循环判断是否有 pending 的软中断,如果

35、有则调用do_softirq() 271. / 来做具体处理。注意:这里又是个 do_softirq()的入口点, 272. / 那么在 _do_softirq() 当中循环处理 10 次软中断的回调函数 273. / 后,如果更有 pending 的话,会又调用到这里。那么在这里则 274. / 又会有可能去调用 _do_softirq() 来处理软中断回调函数。在前 275. / 面介绍 _do_softirq() 时已提到过,处理 10 次还处理不完的 276. / 话说明系统正处于繁忙状态。根据以上分析,我们能试想如果在 277. / 系统非常繁忙时,这个进程将会和 do_softir

36、q()相互交替执行, 278. / 这时此进程占用 CPU 应该会非常高,虽然下面的cond_resched() 279. / 函数做了一些处理,他在处理完一轮软中断后当前处理进程可能会 280. / 因被调度而减少 CPU 负荷,不过在非常繁忙时这个进程仍然有可 281. / 能大量占用 CPU。 282. / 283. while (local_softirq_pending() 284. /* Preempt disable stops cpu going offline. 285. If already offline, well be on wrong CPU: 286. dont

37、process */ 287. if (cpu_is_offline(long)_bind_cpu)288. / 289. / 如果当前被关联的 CPU 无法继续处理则跳转 290. / 到 wait_to_die 标记出,等待结束并退出。 291. / 292. goto wait_to_die; 293. / 294. / 执行 do_softirq() 来处理具体的软中断回调函数。注 295. / 意:如果此时有一个正在处理的软中断的话,则会马上 296. / 返回,还记得前面介绍的 in_interrupt()函数么。 297. / 298. do_softirq(); 299. /

38、300. / 允许当前进程被抢占。 301. / 302. preempt_enable_no_resched(); 303. 304. / 305. / 这个函数有可能间接的调用 schedule()来转换当前 306. / 进程,而且上面已允许当前进程可被抢占。也就是 307. / 说在处理完一轮软中断回调函数时,有可能会转换到 308. / 其他进程。我认为这样做的目的一是为了在某些负载 309. / 超标的情况下不至于让这个进程长时间大量的占用 CPU, 310. / 二是让在有非常多软中断需要处理时不至于让其他进程 311. / 得不到响应。 312. / 313. cond_res

39、ched(); 314. / 315. / 禁止当前进程被抢占。 316. / 317. preempt_disable(); 318. / 319. / 处理完所有软中断了吗?没有的话继续循环以上步骤 320. / 321. 322. / 323. / 待一切都处理完成后,允许当前进程被抢占,并设置 324. / 当前进程状态为可中断状态,继续循环以上所有过程。325. / 326. preempt_enable(); 327. set_current_state(TASK_INTERRUPTIBLE); 328. 329. 330. / 331. / 如果将会停止则设置当前进程为运行状态后

40、直接返回。 332. / 调度器会根据优先级来使当前进程运行。 333. / 334. _set_current_state(TASK_RUNNING); 335. return 0; 336. / 337. / 一直等待到当前进程被停止 338. / 339. wait_to_die: 340. / 341. / 允许当前进程被抢占。 342. / 343. preempt_enable(); 344. /* Wait for kthread_stop */ 345. / 346. / 设置当前进程状态为可中断的状态,这种睡眠状 347. / 态可响应信号处理等。 348. / 349. set_current_state(TASK_INTERRUPTIBLE); 350. / 351. / 判断当前进程是否会被停止,如果不是的话 352. / 则设置进程状态为可中断状态并放弃当前 CPU 353. / 主动转换。也就是说这里将一直等待当前进程 354. / 将被停止时候才结束。 355. / 356. while (!kthread_should_stop() 357. schedule(); 358. set_current_state(T

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 实用文档 > 工作总结

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报