問題很明顯：為什么 4 個(gè)線程為什么被同時(shí)執(zhí)行了？

1 號(hào)和 2 號(hào)這兩個(gè)線程應(yīng)該被優(yōu)先執(zhí)行啊，因?yàn)樗鼈z是實(shí)時(shí)任務(wù)！

怎么結(jié)果是這個(gè)樣子？徹底凌亂了，一點(diǎn)都不符合預(yù)期！

想不出個(gè)所以然，只能求助網(wǎng)絡(luò)！但是沒有找到有價(jià)值的線索。

其中有一個(gè)信息涉及到 Linux 系統(tǒng)的調(diào)度策略，這里記錄一下。

Linux 系統(tǒng)中，為了不讓實(shí)時(shí)任務(wù)徹底占據(jù) CPU 資源，會(huì)讓普通任務(wù)有很小的一段時(shí)間縫隙來執(zhí)行。

在目錄 ／proc／sys／kernel 下面，有 2 個(gè)文件，用來限制實(shí)時(shí)任務(wù)占用 CPU 的時(shí)間：

sched＿rt＿runtime＿us： 默認(rèn)值 950000sched＿rt＿period＿us： 默認(rèn)值 1000000

意思是：在 1000000 微秒（1秒）的周期內(nèi)，實(shí)時(shí)任務(wù)占用 950000 微秒（0．95秒），剩下的 0．05 秒留給普通任務(wù)。

如果沒有這個(gè)限制的話，假如某個(gè) SCHED＿FIFO 任務(wù)的優(yōu)先級(jí)特別高，恰巧出了 bug：一直占據(jù) CPU 資源不放棄，那么我們壓根就沒有機(jī)會(huì)來 kill 掉這個(gè)實(shí)時(shí)任務(wù)，因?yàn)榇藭r(shí)系統(tǒng)無法調(diào)度其他的任何進(jìn)程來執(zhí)行。

而有了這個(gè)限制呢，我們就可以利用這 0．05 秒的執(zhí)行時(shí)間，來 kill 掉有 bug 的那個(gè)實(shí)時(shí)任務(wù)。

回到正題：資料上說，如果實(shí)時(shí)任務(wù)沒有被優(yōu)先調(diào)度，可以把這個(gè)時(shí)間限制刪掉就可以了。方法是：

sysctl －w kernel．sched＿rt＿runtime＿us＝－1

我照做之后，依舊無效！

換一臺(tái)虛擬機(jī)，繼續(xù)測試

難道是電腦環(huán)境的問題嗎？于是，把測試代碼放到另一臺(tái)筆記本里的虛擬機(jī) Ubuntu14．04 里測試。

編譯的時(shí)候，有一個(gè)小問題，提示錯(cuò)誤：

error： ‘for’ loop initial declarations are only allowed in C99 mode

只要把編譯指令中添加 C99 標(biāo)準(zhǔn)就可以了：

gcc －o test test．c －lpthread －std＝c99

執(zhí)行程序，打印信息如下：

＝＝＝＝＞ thread＿index ＝ 2
＝＝＝＝＞ thread＿index ＝ 1
thread＿index 1： SCHED＿FIFO
thread＿index 1： priority ＝ 51
thread＿index 2： SCHED＿FIFO
thread＿index 2： priority ＝ 52
thread＿index 1： num ＝ 0
thread＿index 2： num ＝ 0
thread＿index 2： num ＝ 1
thread＿index 1： num ＝ 1
thread＿index 2： num ＝ 2
thread＿index 1： num ＝ 2
thread＿index 2： num ＝ 3
thread＿index 1： num ＝ 3
thread＿index 2： num ＝ 4
thread＿index 1： num ＝ 4
thread＿index 2： num ＝ 5
thread＿index 1： num ＝ 5
thread＿index 2： num ＝ 6
thread＿index 1： num ＝ 6
thread＿index 2： num ＝ 7
thread＿index 1： num ＝ 7
thread＿index 2： num ＝ 8
thread＿index 1： num ＝ 8
thread＿index 2： num ＝ 9
thread＿index 2： exit
＝＝＝＝＞ thread＿index ＝ 4
thread＿index 4： SCHED＿OTHER
thread＿index 4： priority ＝ 0
thread＿index 1： num ＝ 9
thread＿index 1： exit
＝＝＝＝＞ thread＿index ＝ 3
thread＿index 3： SCHED＿OTHER
thread＿index 3： priority ＝ 0
thread＿index 3： num ＝ 0
thread＿index 4： num ＝ 0
thread＿index 3： num ＝ 1
thread＿index 4： num ＝ 1
thread＿index 3： num ＝ 2
thread＿index 4： num ＝ 2
thread＿index 3： num ＝ 3
thread＿index 4： num ＝ 3
thread＿index 3： num ＝ 4
thread＿index 4： num ＝ 4
thread＿index 3： num ＝ 5
thread＿index 4： num ＝ 5
thread＿index 3： num ＝ 6
thread＿index 4： num ＝ 6
thread＿index 3： num ＝ 7
thread＿index 4： num ＝ 7
thread＿index 3： num ＝ 8
thread＿index 4： num ＝ 8
thread＿index 3： num ＝ 9
thread＿index 3： exit
thread＿index 4： num ＝ 9
thread＿index 4： exit

1 號(hào)和 2 號(hào)線程同時(shí)執(zhí)行，完畢之后，再 3 號(hào)和 4 號(hào)線程同時(shí)執(zhí)行。

但是這同樣也不符合預(yù)期：2 號(hào)線程的優(yōu)先級(jí)比 1 號(hào)線程高，應(yīng)該優(yōu)先執(zhí)行才對！

不知道應(yīng)該怎么查這個(gè)問題了，想不出思路，只好請教 Linux 內(nèi)核的大神，建議檢查一下內(nèi)核版本。

這時(shí)，我才想起來在 Ubuntu16．04 這臺(tái)虛擬機(jī)上因?yàn)槟撤N原因，降過內(nèi)核版本。

往這個(gè)方向去排查了一下，最后確認(rèn)也不是內(nèi)核版本的差異導(dǎo)致的問題。

比較結(jié)果，尋找差異

只好再回過頭來看一下這兩次次打印信息的差異：

工作電腦里的 Ubuntu16．04 中：4 個(gè)線程同時(shí)調(diào)度執(zhí)行，調(diào)度策略和優(yōu)先級(jí)都沒有起作用；

筆記本里的 Ubuntu14．04 中：1 號(hào)和 2 號(hào)實(shí)時(shí)任務(wù)被優(yōu)先執(zhí)行了，說明調(diào)度策略起作用了，但是優(yōu)先級(jí)沒有起作用；

突然， CPU 的親和性從腦袋里蹦了出來！

緊接著立馬感覺到問題出在哪里了：這TMD大概率就是多核引起的問題！

于是我把這 4 個(gè)線程都綁定到 CPU0 上去，也就是設(shè)置 CPU 親和性。

在線程入口函數(shù)  thread＿routine 的開頭，增加下面的代碼：

cpu＿set＿t mask；
int cpus ＝ sysconf（＿SC＿NPROCESSORS＿CONF）；
CPU＿ZERO（＆mask）；
CPU＿SET（0， ＆mask）；
if （pthread＿setaffinity＿np（pthread＿self（）， sizeof（mask）， ＆mask） ＜ 0）
｛
   printf（＂set thread affinity failed！ ＂）；
｝

然后繼續(xù)在 Ubuntu16．04 虛擬機(jī)中驗(yàn)證，打印信息很完美，完全符合預(yù)期：

＝＝＝＝＞ thread＿index ＝ 1
＝＝＝＝＞ thread＿index ＝ 2
thread＿index 2： SCHED＿FIFO
thread＿index 2： priority ＝ 52
thread＿index 2： num ＝ 0
。。。
thread＿index 2： num ＝ 9
thread＿index 2： exit
thread＿index 1： SCHED＿FIFO
thread＿index 1： priority ＝ 51
thread＿index 1： num ＝ 0
。。。
thread＿index 1： num ＝ 9
thread＿index 1： exit
＝＝＝＝＞ thread＿index ＝ 3
thread＿index 3： SCHED＿OTHER
thread＿index 3： priority ＝ 0
＝＝＝＝＞ thread＿index ＝ 4
thread＿index 4： SCHED＿OTHER
thread＿index 4： priority ＝ 0
thread＿index 3： num ＝ 0
thread＿index 4： num ＝ 0
。。。
thread＿index 4： num ＝ 8
thread＿index 3： num ＝ 8
thread＿index 4： num ＝ 9
thread＿index 4： exit
thread＿index 3： num ＝ 9
thread＿index 3： exit

至此，問題真相大白：就是多核處理器導(dǎo)致的問題！

而且這兩臺(tái)測試的虛擬機(jī)，安裝的時(shí)候分配的 CPU 核心是不同的，所以才導(dǎo)致打印結(jié)果的不同。

真相大白

最后，再確認(rèn)一下這 2 個(gè)虛擬機(jī)中的 CPU 信息：

Ubuntu 16．04 中 cpuinfo 信息：

＄ cat ／proc／cpuinfo
processor ： 0
vendor＿id ： GenuineIntel
cpu family ： 6
model  ： 158
model name ： Intel（R） Core（TM） i5－8400 CPU ＠ 2．80GHz
stepping ： 10
cpu MHz  ： 2807．996
cache size ： 9216 KB
physical id ： 0
siblings ： 4
core id  ： 0
cpu cores ： 4
。。。其他信息
processor ： 1
vendor＿id ： GenuineIntel
cpu family ： 6
model  ： 158
model name ： Intel（R） Core（TM） i5－8400 CPU ＠ 2．80GHz
stepping ： 10
cpu MHz  ： 2807．996
cache size ： 9216 KB
physical id ： 0
siblings ： 4
core id  ： 1
cpu cores ： 4
。。。其他信息
processor ： 2
vendor＿id ： GenuineIntel
cpu family ： 6
model  ： 158
model name ： Intel（R） Core（TM） i5－8400 CPU ＠ 2．80GHz
stepping ： 10
cpu MHz  ： 2807．996
cache size ： 9216 KB
physical id ： 0
siblings ： 4
core id  ： 2
cpu cores ： 4
。。。其他信息
processor ： 3
vendor＿id ： GenuineIntel
cpu family ： 6
model  ： 158
model name ： Intel（R） Core（TM） i5－8400 CPU ＠ 2．80GHz
stepping ： 10
cpu MHz  ： 2807．996
cache size ： 9216 KB
physical id ： 0
siblings ： 4
core id  ： 3
cpu cores ： 4
。。。

其他信息

在這臺(tái)虛擬機(jī)中，正好有 4 個(gè)核心，而我的測試代碼正好也創(chuàng)建了 4 個(gè)線程，于是每個(gè)核心被分配一個(gè)線程，一個(gè)都不閑著，同時(shí)執(zhí)行。

因此打印信息中顯示 4 個(gè)線程是并行執(zhí)行的。

這個(gè)時(shí)候，什么調(diào)度策略、什么優(yōu)先級(jí)，都不起作用了�。�準(zhǔn)確的說：調(diào)度策略和優(yōu)先級(jí)，在線程所在的那個(gè) CPU 中是起作用的）

如果我在測試代碼中，一開始就創(chuàng)建 10 個(gè)線程，很可能會(huì)更快發(fā)現(xiàn)問題！

再來看看筆記本電腦里虛擬機(jī) Ubuntu14．04 的 CPU 信息：

＄ cat ／proc／cpuinfo
processor ： 0
vendor＿id ： GenuineIntel
cpu family ： 6
model ： 142
model name ： Intel（R） Core（TM） i5－7360U CPU ＠ 2．30GHz
stepping ： 9
microcode ： 0x9a
cpu MHz ： 2304．000
cache size ： 4096 KB
physical id ： 0
siblings ： 2
core id ： 0
cpu cores ： 2
。。。其他信息
processor ： 1
vendor＿id ： GenuineIntel
cpu family ： 6
model ： 142
model name ： Intel（R） Core（TM） i5－7360U CPU ＠ 2．30GHz
stepping ： 9
microcode ： 0x9a
cpu MHz ： 2304．000
cache size ： 4096 KB
physical id ： 0
siblings ： 2
core id ： 1
cpu cores ： 2
。。。其他信息

在這臺(tái)虛擬機(jī)中，有 2 個(gè)核心，于是 2 個(gè)實(shí)時(shí)任務(wù) 1 號(hào)和 2 號(hào)被優(yōu)先執(zhí)行（因?yàn)槭?2 個(gè)核心同時(shí)執(zhí)行，所以這 2 個(gè)任務(wù)的優(yōu)先級(jí)也就沒什么意義了），結(jié)束之后，再執(zhí)行 3 號(hào)和 4 號(hào)線程。

再思考一下

這一圈測試下來，真的想用鍵盤敲自己的腦袋，怎么就沒有早點(diǎn)考慮到多核的因素呢？！

深層的原因：

之前的很多項(xiàng)目，都是 ARM、mips、STM32等單核情況，思維定式讓我沒有早點(diǎn)意識(shí)到多核這個(gè)屏體因素；

做過的一些 x86 平臺(tái)項(xiàng)目，并沒有涉及到實(shí)時(shí)任務(wù)這樣的要求。一般都是使用系統(tǒng)默認(rèn)的調(diào)度策略，這也是 Linux x86 作為通用電腦，在調(diào)度策略上所關(guān)注的重要指標(biāo)：讓每一個(gè)任務(wù)都公平的使用 CPU 資源。

隨著 x86 平臺(tái)在工控領(lǐng)域的逐漸應(yīng)用，實(shí)時(shí)性問題就顯得更突出、更重要了。

所以才有了 Windows 系統(tǒng)中的 intime，Linux 系統(tǒng)中的 preempt、xenomai 等實(shí)時(shí)補(bǔ)丁。