請(qǐng)問(wèn)進(jìn)程在preempt_disable后，還能永久執(zhí)行而不被調(diào)度嗎？

kerryxi

在preempt_disable后，是不能被其他高優(yōu)先級(jí)進(jìn)程再搶占調(diào)度，但是在時(shí)間片到后，還能夠繼續(xù)執(zhí)行嗎？

謝謝。

asuka2001

回復(fù) 1# kerryxi

spin_lock(deadlock);
spin_lock(deadlock);

然后你看看時(shí)間片到了它是運(yùn)行還是不運(yùn)行。。。。spin_lock()內(nèi)就調(diào)用了 preempt_disable()

humjb_1983

時(shí)間片到了應(yīng)該會(huì)調(diào)度的，之前以為關(guān)中斷了~

kerryxi

謝謝各位牛人解答，但是本人看代碼，系統(tǒng)也是會(huì)調(diào)度的樣子，但是如果preempt_disable被調(diào)度之后，本cpu上面的其他任務(wù)執(zhí)行，如果也調(diào)用spin_lock，這樣這個(gè)cpu不就是被死鎖了嗎？

另外，最常用的get_cpu來(lái)獲取per_cpu變量，就是為了防止本cpu搶占而使得per_cpu變量不一致，如果使用中間調(diào)度出去，per_cpu不也是同樣被**了一致性嗎？

asuka2001

回復(fù) 5# kerryxi

你說(shuō)的死鎖不太明白什么意思！而且你要注意的是 preempt_count是屬于thread_info的，每個(gè)進(jìn)程都有自己的 thread_info。

humjb_1983

再看了下代碼，更正下我之前的說(shuō)法，在preempt_disable之后，如果進(jìn)程不主動(dòng)調(diào)度的話，應(yīng)該不會(huì)調(diào)度到其它進(jìn)程，在最關(guān)鍵的調(diào)度時(shí)機(jī)(中斷/異常返回處)：
ENTRY(resume_kernel)
        DISABLE_INTERRUPTS(CLBR_ANY)
        cmpl $0,TI_preempt_count(%ebp)        # non-zero preempt_count ? //這里判斷了是否可搶占，如果不可搶占的話，就直接返回到內(nèi)核態(tài)了
        jnz restore_all
need_resched:
        movl TI_flags(%ebp), %ecx        # need_resched set ?
        testb $_TIF_NEED_RESCHED, %cl
        jz restore_all
個(gè)人理解，這種情況下應(yīng)該不會(huì)發(fā)生調(diào)度，除非進(jìn)程主動(dòng)schedule。
具體可以請(qǐng)lz使用asuka2001的例子試一下。

kerryxi

謝謝asuka2001的回復(fù)。

preempt_count是屬于thread_info， 就是因?yàn)閠hread_info相關(guān)，所以如果進(jìn)程在preempt_disable后別切換出去了，spin lock才存在死鎖的情況。

如進(jìn)程A：
spin_lock(&lock)
critial_code
...
//need long long time to exec , and it may be scheduled out due to time slice over
spin_unlock

如果調(diào)度器切換當(dāng)前的cpu到進(jìn)程B，B也要使用相同的lock，此時(shí)cpu就不會(huì)永久的spin來(lái)等待同cpu的spin lock釋放，但是顯然此spin lock不會(huì)被釋放了。
進(jìn)程B：
spin_lock(&lock)
critial_code
spin_unlock

謝謝。

asuka2001

回復(fù) 8# kerryxi

。。。其實(shí)你自己都已經(jīng)回答了你自己的問(wèn)題了。

既然是 原子上下文，要是能調(diào)度出去，那使用 spinlock()還有什么意義呢。

asuka2001

回復(fù) 9# asuka2001

不過(guò)我自己開(kāi)始二胡了。。。我做了下測(cè)試，結(jié)果讓我郁悶了。

ps -eo pid,state,args,psr | grep R
  PID S COMMAND                     PSR
    7 R [migration/1]                 1
   10 R [watchdog/1]                  1
   11 R [events/0]                    0
   12 R [events/1]                    1
3839 R /usr/bin/python /usr/bin/no   0
4112 R [loop1]                       1
4135 R /usr/bin/python /usr/bin/ci   0
5058 R /usr/lib/vmware-tools/sbin6   0
8984 R insmod hello.ko               1
9296 R ps -eo pid,state,args,psr     0
9297 R grep R                        0

hello.ko是死鎖內(nèi)核模塊，我插入了之后，結(jié)果還是有其他的內(nèi)核線程認(rèn)為自己是 R在 CPU 1上的。。。這個(gè)是為什么呢？

-------------

自己腦袋發(fā)蒙。。。R值得不是運(yùn)行，而是 running or runnable！