關鍵字：LabVIEW 自動多線程語言

一般情況下，運行一個 VI，LabVIEW 至少會在兩個線程內運行它：一個界面線程（UI Thread），用于處理界面刷新，用戶對控件的操作等等；還有一個執行線程，負責 VI 除界面操作之外的其它工作。LabVIEW 是自動多線程的編程語言，只要 VI 的代碼可以并行執行，LabVIEW 就會將它們分配在多個執行線程內同時運行。

圖1 是一個正在運行的簡單 VI，它由單獨一個一直在運行的循環組成。在此情況下，這個執行循環的線程運算負擔特別重，其它線程則基本空閑。在單 CPU 計算機上，這個線程將會占用幾乎 100% 的 CPU 時間。圖1 中的任務管理器是在一個雙核 CPU 計算機上截取的。這個循環雖然在每一個時刻只能運行在一個線程上，但這并不表示他始終不變的就固定在一個線程上。他可能在這個時刻運行在這個線程上，另一時刻又被調度到其他線程上去運行了。

因此，圖1 這個程序最多只能占用兩個 CPU 內核 50% 的總 CPU 時間，兩個 CPU 內核各被占用一些。

圖1：雙核 CPU 計算機執行一個計算繁重的任務

圖2 是當程序有兩個并行的繁重計算任務時的情況，這時 LabVIEW 會自動把兩個任務分配到兩個線程中去。這時即便是雙核 CPU 也會被 100% 占用。

圖2：雙核 CPU 計算機執行兩個計算繁重的任務

從上面的例子，我們可以得出如下兩個結論。

1. 在 LabVIEW 上編寫多線程程序非常方便，我們應該充分利用這個優勢。一般情況下，編寫程序時應當遵循這樣的原則：可以同時運行的模塊就并排擺放，千萬不要用連線，順序框等方式強制它們依次執行。在并行執行時， LabVIEW 會自動地把它們安排在在不同線程下同時運行，以提高程序的執行速度，節省程序的運行時間。今后多核計算機將成為主流配置，多線程的優勢會更為明顯。

特殊的情況也是有的，即用多線程時，運行速度反而慢。 以后我們再來詳細介紹此類特殊情況。

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

此類問題最簡單的解決方法就是在循環內加一個延時。在圖1、圖2 的例子中，如果在每個循環內加上 100 毫秒的延時，CPU 占用率就會接近為0。

對于總運行時間較短的循環（假如CPU 占用總時間不足 100毫秒）就沒有必要再加延時了。

在很多情況下，運行時間很長的循環往往都只是為了等待某一個任務的完成，在此類循環體的內部幾乎沒有耗時較多的、又有意義的運算，所以必須在循環框內加延時。

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

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

在處理界面操作的 VI 中，常常會使用到 While 循環內套一個 Event Structure 這種結構形式。在這種情況下，就沒有必要再在循環內添加延時了。因為程序在執行到 Event Structure 時，如果沒有事件產生，程序不再繼續執行下去，而是等待某一事件的發生。這是，運行這段代碼的線程會暫時休眠，不占用任何 CPU 資源，一直等到有事件發生，這個線程才會重新被喚醒，繼續工作。