LabVIEW 是自動(dòng)多線程語(yǔ)言

關(guān)鍵字：LabVIEW 自動(dòng)多線程語(yǔ)言

一般情況下，運(yùn)行一個(gè) VI，LabVIEW 至少會(huì)在兩個(gè)線程內(nèi)運(yùn)行它：一個(gè)界面線程（UI Thread），用于處理界面刷新，用戶對(duì)控件的操作等等；還有一個(gè)執(zhí)行線程，負(fù)責(zé) VI 除界面操作之外的其它工作。LabVIEW 是自動(dòng)多線程的編程語(yǔ)言，只要 VI 的代碼可以并行執(zhí)行，LabVIEW 就會(huì)將它們分配在多個(gè)執(zhí)行線程內(nèi)同時(shí)運(yùn)行。

圖1 是一個(gè)正在運(yùn)行的簡(jiǎn)單 VI，它由單獨(dú)一個(gè)一直在運(yùn)行的循環(huán)組成。在此情況下，這個(gè)執(zhí)行循環(huán)的線程運(yùn)算負(fù)擔(dān)特別重，其它線程則基本空閑。在單 CPU 計(jì)算機(jī)上，這個(gè)線程將會(huì)占用幾乎 100% 的 CPU 時(shí)間。圖1 中的任務(wù)管理器是在一個(gè)雙核 CPU 計(jì)算機(jī)上截取的。這個(gè)循環(huán)雖然在每一個(gè)時(shí)刻只能運(yùn)行在一個(gè)線程上，但這并不表示他始終不變的就固定在一個(gè)線程上。他可能在這個(gè)時(shí)刻運(yùn)行在這個(gè)線程上，另一時(shí)刻又被調(diào)度到其他線程上去運(yùn)行了。

因此，圖1 這個(gè)程序最多只能占用兩個(gè) CPU 內(nèi)核 50% 的總 CPU 時(shí)間，兩個(gè) CPU 內(nèi)核各被占用一些。

圖1：雙核 CPU 計(jì)算機(jī)執(zhí)行一個(gè)計(jì)算繁重的任務(wù)

圖2 是當(dāng)程序有兩個(gè)并行的繁重計(jì)算任務(wù)時(shí)的情況，這時(shí) LabVIEW 會(huì)自動(dòng)把兩個(gè)任務(wù)分配到兩個(gè)線程中去。這時(shí)即便是雙核 CPU 也會(huì)被 100% 占用。

圖2：雙核 CPU 計(jì)算機(jī)執(zhí)行兩個(gè)計(jì)算繁重的任務(wù)

從上面的例子，我們可以得出如下兩個(gè)結(jié)論。

1. 在 LabVIEW 上編寫(xiě)多線程程序非常方便，我們應(yīng)該充分利用這個(gè)優(yōu)勢(shì)。一般情況下，編寫(xiě)程序時(shí)應(yīng)當(dāng)遵循這樣的原則：可以同時(shí)運(yùn)行的模塊就并排擺放，千萬(wàn)不要用連線，順序框等方式強(qiáng)制它們依次執(zhí)行。在并行執(zhí)行時(shí)， LabVIEW 會(huì)自動(dòng)地把它們安排在在不同線程下同時(shí)運(yùn)行，以提高程序的執(zhí)行速度，節(jié)省程序的運(yùn)行時(shí)間。今后多核計(jì)算機(jī)將成為主流配置，多線程的優(yōu)勢(shì)會(huì)更為明顯。

特殊的情況也是有的，即用多線程時(shí)，運(yùn)行速度反而慢。 以后我們?cè)賮?lái)詳細(xì)介紹此類(lèi)特殊情況。

2. 假如有一個(gè)或某幾個(gè)線程占用了 100% 的 CPU，此時(shí)系統(tǒng)對(duì)其他線程就會(huì)反應(yīng)遲鈍。例如，程序的執(zhí)行線程占用了100% 的 CPU，那么用戶對(duì)界面的操作就會(huì)遲遲得不到響應(yīng)，甚至于用戶會(huì)誤認(rèn)為程序死鎖了。所以在程序中要盡量避免出現(xiàn) 100% 占用 CPU 的情況。 目前大多數(shù)的計(jì)算機(jī)還是單核單個(gè) CPU 的，因此要避免任何一個(gè)線程試圖 100% 占用 CPU 的情況（如圖1、圖2 所示的程序）。

此類(lèi)問(wèn)題最簡(jiǎn)單的解決方法就是在循環(huán)內(nèi)加一個(gè)延時(shí)。在圖1、圖2 的例子中，如果在每個(gè)循環(huán)內(nèi)加上 100 毫秒的延時(shí)，CPU 占用率就會(huì)接近為0。

對(duì)于總運(yùn)行時(shí)間較短的循環(huán)（假如CPU 占用總時(shí)間不足 100毫秒）就沒(méi)有必要再加延時(shí)了。

在很多情況下，運(yùn)行時(shí)間很長(zhǎng)的循環(huán)往往都只是為了等待某一個(gè)任務(wù)的完成，在此類(lèi)循環(huán)體的內(nèi)部幾乎沒(méi)有耗時(shí)較多的、又有意義的運(yùn)算，所以必須在循環(huán)框內(nèi)加延時(shí)。

對(duì)于那些確實(shí)非常耗費(fèi) CPU資源 的運(yùn)算（如需要 100% 地占用 CPU 幾秒鐘甚至更長(zhǎng)的時(shí)間），最好也在循環(huán)內(nèi)插入少量延時(shí)，從而讓 CPU 至少 空出 10% 的時(shí)間給其它線程或進(jìn)程。你的程序會(huì)因此而多運(yùn)行 10% 的時(shí)間。 但是由于 CPU 可以及時(shí)處理其他線程的需求，比如界面操作等，其他后臺(tái)程序也不會(huì)被打斷，用戶反而會(huì)感覺(jué)到程序似乎運(yùn)行得更加流暢。反之，假如你的程序太霸道了，CPU長(zhǎng)期被某些運(yùn)算所霸占，而別的什么都不能做，這樣的程序，用戶是不可能滿意的。

還有這樣一種情況，比如某些運(yùn)算可能需要程序循環(huán) 1,000,000次，每執(zhí)行一次僅需要 0.1 毫秒。此時(shí)如果在每次循環(huán)里都插入延時(shí)，即使是 1 毫秒的延時(shí)，也會(huì)令程序速度減慢 10 倍。 這當(dāng)然是不能容忍的。這種情況下，就不能在每次循環(huán)都加延時(shí)了，但可以采用每一千次循環(huán)后加上 10 毫秒延時(shí)的策略。此時(shí)，程序僅減慢 10% 左右，而 CPU 也有處理其他工作的時(shí)間了。

在處理界面操作的 VI 中，常常會(huì)使用到 While 循環(huán)內(nèi)套一個(gè) Event Structure 這種結(jié)構(gòu)形式。在這種情況下，就沒(méi)有必要再在循環(huán)內(nèi)添加延時(shí)了。因?yàn)槌绦蛟趫?zhí)行到 Event Structure 時(shí)，如果沒(méi)有事件產(chǎn)生，程序不再繼續(xù)執(zhí)行下去，而是等待某一事件的發(fā)生。這是，運(yùn)行這段代碼的線程會(huì)暫時(shí)休眠，不占用任何 CPU 資源，一直等到有事件發(fā)生，這個(gè)線程才會(huì)重新被喚醒，繼續(xù)工作。