博客访问： 144555
博文数量： 36
博客积分： 883
博客等级： 准尉
技术积分： 656
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
死锁：就是多个进程（≥2）因为争夺资源而相互等待的一种现象，若无外力推动，将无法继续运行下去。
注意，只有在多进程或者多线程之间或者他们与中断之间相互通讯或者共享资源才有可能发生死锁，单线程或者进程之间没有联系的话，一般不会发生死锁。锁的种类比较多，这里主要说自旋锁和信号量。两者的差别就在于前者获得不到资源时的动作是不断的资源（即忙转浪费cpu的cycles）而后者则表现为睡眠等待。
死锁的基本情况如下：
（一）、自旋锁
& &1 递归使用：同一个进程或线程中，申请自旋锁，但没有释放之前又再次申请，一定产生死锁。
& & 2 进程得到自旋锁后阻塞，睡眠：在获得自旋锁之后调用copy_from_user()、copy_to_ser()、和kmalloc（）等有可能引起阻塞的函数。
& & 3 中断中没有关中断，或着因为申请未释放的自旋锁：在中断中使用自旋锁是可以的，应该在进入中断的时候关闭中断，不然中断再次进入的时候，中断处理函数会自旋等待自旋锁可以再次使用。或者在进程中申请了自旋锁，释放前进入中断处理函数，中断处理函数又申请同样的自旋锁，这将导致死锁。
& & 4 中断与中断下半部共享资源和中断与进程共享资源死锁出现的情况类似。
& & 5 中断下半部与进程共享资源和中断与进程共享资源死锁出现的情况类似。
& & 自旋锁三种状态：
& & 自旋锁保持期间是抢占失效的（内核不允许被抢占）。
& & 1 单CPU且内核不可抢占：
& & & 自旋锁的所有操作都是空。不会引起死锁，内核进程间不存在并发操作进程，进程与中断仍然可能共享数据，存在并发操作，此时内核自旋锁已经失去效果。
& & 2 单CPU且内核可抢占：
& & & 当获得自旋锁的时候，禁止内核抢占直到释放锁为止。此时可能存在死锁的情况是参考自旋锁可能死锁的一般情况。
& & & 禁止内核抢占并不代表不会进行内核调度，如果在获得自旋锁后阻塞或者主动调度，内核会调度其他进程运行，被调度的内核进程返回用户空间时，会进行用户抢占，此时调用的进程再次申请上次未释放的自旋锁时，会一直自旋。但是内核被禁止抢占，从而造成死锁。
& & & 内核被禁止抢占，但此时中断并没被禁止，内核进程可能因为中断申请自旋锁而死锁。
& & 3 多CPU且内核可抢占：
& & & 这才是是真正的SMP的情况。当获得自旋锁的时候，禁止内核抢占直到释放锁为止。
（二）信号量
& &&1 递归使用：&同理，在同一个进程或线程中，申请了信号量，但没有释放之前又再次申请，进程会一直睡眠，这种情况一定死锁。
& & 2 进程得到信号量后阻塞，睡眠：由于获取到信号量的进程阻塞或者随眠，其他在获取不到后信号量也会进入睡眠等待，这种情况可能造成死锁。
& & 3 中断中申请信号量：由于信号量在获取不到自旋锁后会进入睡眠等待，中断处理函数不允许睡眠，如果睡眠，中断将无法返回。
& & 4 中断下半部申请信号量：中断下半部允许睡眠，这种情况不会造成死锁。
& & 5 俩个进程相互等待资源：进程1获得信号量A，需要信号量B，在进程1需要信号量B之前进程2获得信号量B，需要信号量A。进程1、2因相互等待资源而死锁。
上面是死锁的基本情况和类型。linux本身就提供了检测死锁的机制，如下：
（一）D状态死锁检测
所谓D状态死锁：进程长时间（系统默认配置120秒）处于TASK_UNINTERRUPTIBLE 睡眠状态，这种状态下进程不响应异步信号。如：进程与外设硬件的交互（如read），通常使用这种状态来保证进程与设备的交互过程不被打断，否则设备可能处于不可控的状态。
对于这种死锁的检测linux提供的是hungtask机制，主要内容集中在Hung_task.c文件中。具体实现原理如下：
&1）、系统创建normal级别的khungtaskd内核线程，内核线程每120秒检查一次，检查的内容：遍历所有的线程链表，发现D状态的任务，就判断自最近一次切换以来是否还有切换发生，若是有，则返回。若没有发生切换，则把任务的所有调用栈等信息打印出来。
2）、具体实现过程如下：
首先，hung_task_init创建一个名为khungtaskd的内核线程，内核线程的工作由watchdog来完成。
static int __init hung_task_init(void)
&&&&atomic_notifier_chain_register(&panic_notifier_list, &panic_block);
&&&&watchdog_task = kthread_run(watchdog, NULL, "khungtaskd");
&&&&return 0;
其次，我们看watchdog的实现：
static int watchdog(void *dummy)
&&&&&&&&//将内核线程设置为normal级别
&&&&set_user_nice(current, 0);
&&&&for ( ; ; ) {
//设置hungtask的校验时间间隔，用户可以修改这个时间，默认为120秒
&&&&&&&&unsigned long timeout = sysctl_hung_task_timeout_secs;
&&&&&&&&while (schedule_timeout_interruptible(timeout_jiffies(timeout)))
&&&&&&&&&&&&timeout = sysctl_hung_task_timeout_secs;
//核心的检查代码在下面的函数中实现。&&&&&&&&check_hung_uninterruptible_tasks(timeout);
&&&&return 0;
最后，我们分析一下hungtask的核心实现check_hung_uninterruptible_tasks，如下：
static void check_hung_uninterruptible_tasks(unsigned long timeout)
&&&&int max_count = sysctl_hung_task_check_count;
&&&&int batch_count = HUNG_TASK_BATCHING;
&&&&struct task_struct *g, *t;
&&&& * If the system crashed already then all bets are off,
&&&& * do not report extra hung tasks:
//判断系统是否已经die、oops或者panic了，若是系统已经crash了，就无需再做hungtask了。
&&&&if (test_taint(TAINT_DIE) || did_panic)
&&&&&&&&return;
&&&&rcu_read_lock();
//检查进程的列表，寻找D状态的任务
&&&&do_each_thread(g, t) {
//判断用户是否设置了检查进程的数量，若是已经达到用户设置的限制，就跳出循环。
&&&&&&&&if (!max_count--)
&&&&&&&&&&&&goto unlock;
//判断是否到达批处理的个数，做这个批处理的目的就是因为整个检查是在关抢占的前提下进行的，可能进程列表的进程数很多，为了防止hungtask垄断cpu，所以，做了一个批处理的限制，到达批处理的数量后，就放一下权，给其他的进程运行的机会。
&&&&&&&&if (!--batch_count) {
&&&&&&&&&&&&batch_count = HUNG_TASK_BATCHING;
&&&&&&&&&&&&rcu_lock_break(g, t);
&&&&&&&&&&&&/* Exit if t or g was unhashed during refresh. */
&&&&&&&&&&&&if (t->state == TASK_DEAD || g->state == TASK_DEAD)
&&&&&&&&&&&&&&&&goto unlock;
&&&&&&&&/* use "==" to skip the TASK_KILLABLE tasks waiting on NFS */
//如果进程处于D状态，就开始把相关的信息显示出来了。
&&&&&&&&if (t->state == TASK_UNINTERRUPTIBLE)
&&&&&&&&&&&&check_hung_task(t, timeout);
&&&&} while_each_thread(g, t);
&&&&rcu_read_unlock();
static void check_hung_task(struct task_struct *t, unsigned long timeout)
//统计进程的切换次数=主动切换次数+被动切换次数
&&&&unsigned long switch_count = t->nvcsw + t->nivcsw;
&&&& * Ensure the task is not frozen.
&&&& * Also, when a freshly created task is scheduled once, changes
&&&& * its state to TASK_UNINTERRUPTIBLE without having ever been
&&&& * switched out once, it musn
怎么样，经过上面的分析，可以发现其实原理很简单。
（二）R状态死锁检测
所谓R状态死锁：进程长时间（系统默认配置60秒）处于TASK_RUNNING&状态垄断cpu而不发生切换，一般情况下是进程关抢占后长时候干活，有时候可能进程关抢占后处于死循环或者睡眠后，这样就造成系统异常。
对于这种死锁的检测机制linux提供的机制是softlockup。主要集中在softlockup.c文件中。
1）、系统创建一个fifo的进程，此进程周期性的清一下时间戳（per cpu），而系统的时钟中断中会被softlockup挂入一个钩子（softlockup_tick）,这个钩子就是每个时钟中断到来的时候都检查是否每cpu的时间戳被touch了，若在阀值60秒内都没有被touch，系统就打印调试信息。
2）、让我们分析一下具体的实现：
首先，系统初始化的时候为每个cpu创建一个watchdog线程，这个线程是fifo的。具体实现如下：
static int __init spawn_softlockup_task(void)
&&&&void *cpu = (void *)(long)smp_processor_id();
&&&&int err;
//可以通过启动参数禁止softlockup
&&&&if (nosoftlockup)
&&&&&&&&return 0;
//下面两个回调函数就是为每个cpu创建一个watchdog线程
&&&&err = cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
&&&&if (err == NOTIFY_BAD) {
&&&&&&&&BUG();
&&&&&&&&return 1;
&&&&cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
&&&&register_cpu_notifier(&cpu_nfb);
&&&&atomic_notifier_chain_register(&panic_notifier_list, &panic_block);
&&&&return 0;
static int __cpuinit
cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
&&&&int hotcpu = (unsigned long)hcpu;
&&&&struct task_struct *p;
&&&&switch (action) {
&&&&case CPU_UP_PREPARE:
&&&&case CPU_UP_PREPARE_FROZEN:
&&&&&&&&BUG_ON(per_cpu(softlockup_watchdog, hotcpu));
//创建watchdog内核线程
&&&&&&&&p = kthread_create(watchdog, hcpu, "watchdog/%d", hotcpu);
&&&&&&&&if (IS_ERR(p)) {
&&&&&&&&&&&&printk(KERN_ERR "watchdog for %i failed\n", hotcpu);
&&&&&&&&&&&&return NOTIFY_BAD;
//将时间戳清零
&&&&&&&&per_cpu(softlockup_touch_ts, hotcpu) = 0;
//设置watchdog
&&&&&&&&per_cpu(softlockup_watchdog, hotcpu) = p;
&&&&&&&&kthread_bind(p, hotcpu);
&&&&&&&&break;
&&&&case CPU_ONLINE:
&&&&case CPU_ONLINE_FROZEN:
//唤醒watchdog这个内核线程&&&&&&&&wake_up_process(per_cpu(softlockup_watchdog, hotcpu));
&&&&&&&&break;
&&&&return NOTIFY_OK;
其次，我们看一下内核线程watchdog的实现，如下：
static int watchdog(void *__bind_cpu)
//将watchdog设置为fifo
&&&&struct sched_param param = { .sched_priority = MAX_RT_PRIO-1 };
&&&&sched_setscheduler(current, SCHED_FIFO, ?m);
//清狗，即touch时间戳
&&&&/* initialize timestamp */
&&&&__touch_softlockup_watchdog();
//当前进程可以被信号打断
&&&&set_current_state(TASK_INTERRUPTIBLE);
&&&& * Run briefly once per second to reset the softlockup timestamp.
&&&& * If this gets delayed for more than 60 seconds then the
&&&& * debug-printout triggers in softlockup_tick().
&&&&while (!kthread_should_stop()) {
//核心实现就是touch时间戳，让出cpu
&&&&&&&&__touch_softlockup_watchdog();
&&&&&&&&schedule();
&&&&&&&&if (kthread_should_stop())
&&&&&&&&&&&&break;
&&&&&&&&set_current_state(TASK_INTERRUPTIBLE);
&&&&__set_current_state(TASK_RUNNING);
&&&&return 0;
最后，softlockup在时钟中断中挂上一个钩子softlockup_tick，每个时钟中断都来检查watchdog这个fifo进程是否有touch过时间戳，若是60秒都没有touch过，就向系统上报异常信息了，如下：
void softlockup_tick(void)
//取得当前的cpu
&&&&int this_cpu = smp_processor_id();
//获得当前cpu的时间戳
&&&&unsigned long touch_ts = per_cpu(softlockup_touch_ts, this_cpu);
&&&&unsigned long print_ts;
//获得进程当前的寄存器组
&&&&struct pt_regs *regs = get_irq_regs();
&&&&unsigned long now;
//如果没有打开softlockup，就将这个cpu对应的时间戳清零
&&&&/* Is detection switched off? */
&&&&if (!per_cpu(softlockup_watchdog, this_cpu) || softlockup_thresh <= 0) {
&&&&&&&&/* Be sure we don
怎么样，说白了，也不难，就是两条线并行工作：一条线是fifo级别的内核线程负责清时间戳，另一条线是时钟中断定期检查时间戳是否有被清过，若是到了阀值都没有被请过，则打印softlockup的信息。
（三）长时间关中断检测
长时间关中断检测可以有几种实现机制，而利用nmi watchdog来检查这种长时间关中断情况，是比较简单的。其原理是需要软硬件配合，硬件通常提供一个计数器（可以递增也可以递减），当记数到某个值得时候，系统就硬件复位。而nmi watchdog就定期（小于这个计数到达系统复位的时间）的去清一下系统的计数，若是某个进程长时间关中断，则可能导致nmi watchdog得不到清，最终系统复位。
阅读(18318) | 评论(1) | 转发(11) |
下一篇：没有了
相关热门文章
给主人留下些什么吧！~~
文明上网，理性发言...
请登录后评论。新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
白手起家, 积分 23, 距离下一级还需 177 积分
论坛徽章:0
本帖最后由 oceanljp 于
17:39 编辑
最近在看宋宝华的《设备驱动开发详解》第二版，看到自旋锁的部分，有些疑惑，所以来请教下大家。
下面是我参考一些网络上的资料得出的一些想法，不知正确与否，记录下来大家讨论下：
（1） linux上的自旋锁有三种实现：
& && && & 1. 在单cpu，不可抢占内核中，自旋锁为空操作。
& && && & 2. 在单cpu，可抢占内核中，自旋锁实现为“禁止内核抢占”，并不实现“自旋”。
& && && & 3. 在多cpu，可抢占内核中，自旋锁实现为“禁止内核抢占” + “自旋”。
（2） 关于抢占式内核与非抢占式内核：
& && && & 在非抢占式内核中，如果一个进程在内核态运行，其只有在以下两种情况会被切换：
& && && & 1.&&其运行完成（返回用户空间）
& && && & 2.&&主动让出cpu（即主动调用schedule或内核中的任务阻塞——这同样也会导致调用schedule）
& && && & 在抢占式内核中，如果一个进程在内核态运行，其只有在以下四种情况会被切换：
& && && & 1.&&其运行完成（返回用户空间）
& && && & 2.&&主动让出cpu（即主动调用schedule或内核中的任务阻塞——这同样也会导致调用schedule）
& && && & 3.&&当从中断处理程序正在执行，且返回内核空间之前（此时可抢占标志premptcount须为0） 。
& && && & 4.&&当内核代码再一次具有可抢占性的时候，如解锁及使能软中断等。
& && && &在宋宝华的书中，有提到在使用自旋锁时，要避免用来保护“包含引起阻塞的代码”，因为阻塞意味着要进行进程的切换。这点让我很迷惑。因为在可抢占式内核中使用自旋锁，是“禁止内核抢占”的，既然“禁止内核抢占”怎么又会发生进程的切换呢？
& && && &现在我是这么想的：禁止内核抢占只是关闭“可抢占标志”，而不是禁止进程切换。显式使用schedule或进程阻塞（此也会导致调用schedule）时，还是会发生进程调度的。
& && && &这里补充一些想法：宋宝华的书上说，在使用自旋锁保护临界区时，如临界区中因“包含引起阻塞代码”而引发阻塞，从而引起进程切换后，若另一进程企图获得本自旋锁，死锁会发生。
& && && &个人感觉，只有在多cpu，内核可抢占的情况会发生死锁。而在单cpu，内核可抢占或不可抢占的情况，不会发生死锁，但此时自旋锁失效（即无法实现保护临界区的功能）。这是因为多cpu可抢占内核实现了“自旋”，所以会导致死锁；而单cpu可抢占或不可抢占内核，没有实现“自旋”，仅仅是“禁止内核抢占”，因此不会发生死锁，但是会发生无保护的重复进入临界区的情况（即无法实现保护临界区的功能）。
以上观点只是个人想法，不当之处，还请各位指出，谢谢。
, , , , , , ,
可用积分 +6
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
稍有积蓄, 积分 233, 距离下一级还需 267 积分
论坛徽章:1
阻塞当然意味着要进行进程切换，当前进程阻塞也就是说当前进程去sleep了，这时候kernel会调用scheduler来选择一个合适的进程进入running状态。这个过程和禁止抢占不矛盾。
使用自旋锁时，要避免用来保护“包含引起阻塞的代码”，我的理解是这样的：自旋锁的实现是“抢的到就继续，否则就自旋——空循环”，如果一个进程长时间持有自旋锁，将会导致其他争用该自旋锁的进程长时间处于自旋状态，而进程自旋的时候其实什么都不做，白白消耗其时间片，浪费CPU时间。所以使用自旋锁的一个原则就是不要长时间持有它。如果在持有自旋锁的期间进程sleep了，那将导致持有该锁的时间长度不可预期(鬼知道这个进程什么时候会被wake up)，这显然会违反使用自旋锁的上述原则。
白手起家, 积分 23, 距离下一级还需 177 积分
论坛徽章:0
同意楼上第一个观点。
第二个观点，使用自旋锁时，避免用来保护“包含引起阻塞的代码”的主要原因，应该是避免在阻塞并发生进程调度后，再次进入临界区引起的“死锁”或“无保护重复进入临界区的错误”。“不长时间持有自旋锁”应该不是其主要原因。
而且如我在一楼所述，自旋锁的实现在不同的情况下是不同的，并不都是“抢的到就继续，否则就自旋——空循环”。应分开讨论。
在单cpu系统中的自旋锁，并不具备“自旋”功能。
稍有积蓄, 积分 298, 距离下一级还需 202 积分
论坛徽章:0
单cpu 非抢占：&&内核中的执行天然的隔绝了进程切换。要注意 自旋锁不能防止系统调用被 硬中断或者异常抢占去。
单cpu抢占：&&spin_lock只 要关抢占，否则在本cpu起不到任何 锁的作用。 这要求临界区尽量的短小
多cpu 抢占： 自选就意味着核间呼斥，本cpu上的进程间互斥，由其关抢占性质实现 ！
&&多cpu 非抢占： 自选就意味着核间呼斥就可以了 ！
稍有积蓄, 积分 233, 距离下一级还需 267 积分
论坛徽章:1
怎么会发生死锁呢？
咱们分情况来看一下：
1. 单核非抢占：此时spinlock什么都不做，如果持有锁的进程阻塞，内核会通过scheduler选择其他进程执行，可能会造成临界区的冲突；
2. 单核抢占：此时spinlock只是禁止抢占，防止持有锁的进程被抢占而引起的临界区访问冲突，但是如果持有锁的进程阻塞，内核会通过scheduler选择其他进程执行，也可能会造成临界区的冲突；
3. 多核非抢占：此时spinlock应该是“多个CPU对锁抢的到就继续，否则就空循环”，持有锁的进程阻塞会会使得其他CPU争用该锁的时候忙等，引起系统性能下降；
4. 多核抢占：此时spinlock首先禁止持有锁的进程所在的CPU抢占，然后“多个CPU对锁抢的到就继续，否则就空循环”，持有锁的进程阻塞的话，一方面在持有锁的CPU上可能会造成临界区的冲突，另一方面会使得其他CPU争用该锁的时候忙等，造成系统性能下降。
所有这四种情况应该都不会导致死锁的发生。
白手起家, 积分 23, 距离下一级还需 177 积分
论坛徽章:0
死锁是有可能发生的。
死锁发生在多核的情况，下面来分析一下：
首先，对于多核抢占与多核非抢占的情况，在使用自旋锁时，其情况基本是一致的。
因为在多核抢占的情况下，使用自旋锁会禁止内核抢占，这样多核抢占就相当于多核非抢占的情况。
那下面就只分析多核非抢占的情况。
假设系统有A，B两个CPU。
A上正在运行的a进程已获得自旋锁，并在临界区运行。
B上正在运行的b进程企图获得自旋锁，但由于自旋锁已被占用，于是b进程在B CPU上“自旋”空转。
这时，如果在A上的a进程因程序阻塞，而被休眠。接着A会切换运行另一进程c。
若这个进程c也企图获取自旋锁，c进程同样会因为锁已被占用，而在A上“自旋”空转。
这时候，A上的a进程与c进程就形成了死锁。a进程需要被c进程占用的CPU,c进程需要被a进程占用的锁。
至于在单cpu内核上不会出现上述情况，因为单cpu上的自旋锁实际没有“自旋功能”。
稍有积蓄, 积分 298, 距离下一级还需 202 积分
论坛徽章:0
oh,楼上的兄弟，不得不再说一下， 自旋锁的临界区，禁止使用睡眠。&&如果你想使用睡眠锁请使用 mutex, semaphore,rt_mutex 。
自旋锁有别于睡眠锁，就是为了提高多核条件下的运行效率。 自选锁临界区sleep，等于自残！
家境小康, 积分 1104, 距离下一级还需 896 积分
论坛徽章:0
看到这种分类就烦，单核下明明就不是自旋锁非要用同一个名字，又赋予其不同的语义。
白手起家, 积分 23, 距离下一级还需 177 积分
论坛徽章:0
呵呵，多谢这位兄弟指导，我只是看到宋宝华书上说，在自旋锁的临界区阻塞会发生死锁，与我想的不大一致，拿出来和大家探讨探讨。
丰衣足食, 积分 703, 距离下一级还需 297 积分
论坛徽章:0
单核下应该没自旋锁吧，这个应该只在smp中的概念吧
北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号：
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处kernel preemption
以上的代码中, 因为有了内核抢占( kernel preemption)，你可以在任何地方进行抢占。当重新调度时，你可能在使用另外一个cpu并且'cpu'的值不再指向当前的cpu了。
基于16个网页-
preemptive ability of linux kernel
Kernel Preemption Time
Preemption Model
preempted core
preemptable kernel
preemptive kernel
更多收起网络短语
kernel preemption
- 引用次数：3
In Chapter 2, we focus on the kernel preemption strategy and scheduling algorithms. For the kernel preemption, we will examine two improved schemes and patches, with emphasis on the analysis of the inserting-preemption-point scheme.
接着本文从Linux的内核抢占和调度机制上进行了重点分析和研究：在内核抢占方面，分析了改进可抢占性的两种方案及补丁，其中重点分析了插入抢占点的方案；在调度机制方面，分析了Linux2.4.18的进程调度部分，讨论了两种经典实时调度算法。
参考来源 - 嵌入式Linux及其调度策略的研究
&2,447,543篇论文数据，部分数据来源于
所以 FPU 代码必须始终被锁定，以防止内核抢占。
So FPU code must always be locked against kernel preemption.
内核抢占补丁在2.5系列中就已经被打上，接下来在2.6中也会打。
The kernel preemption patch has been merged into the 2.5 series and subsequently will make it into 2.6.
这一过程在目标模块创建了一个特定部分，以记录使用的编译器版本号，内核版本号，是否使用内核抢占等信息。
This creates a special section in the object module that contains information like the compiler version used, the kernel version, whether kernel preemption is used, and so on.
$firstVoiceSent
- 来自原声例句
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！
请问您想要如何调整此模块？
感谢您的反馈，我们会尽快进行适当修改！