詳細講解一下不同的LabVIEW多線程同步機制

我們提到過使用局部變量、全局變量時，必須注意處理好并發(fā)訪問。

舉個例子：有A、B、C三個線程在并發(fā)執(zhí)行。A線程修改了變量V的值，期望線程C能夠讀取到最新的值。B線程卻在C線程讀取變量V的值之前修改了V的值。這種情況我們說變量V被污染了、數(shù)據(jù)臟了。 要處理好變量的并發(fā)訪問、多線程對變量的訪問，我們需要使用同步機制。

在多線程軟件設計中，不僅僅對變量的訪問，對任何競爭性資源的使用/訪問都必須使用合理的同步機制進行管理。比如，有兩個線程都需要使用某個模擬輸出通道，但是模擬輸出通道只有1個、同一時刻只能由1個線程使用，這種情況下我們把這個模擬輸出通道稱作競爭性資源。

如果不對這個模擬輸出通道的訪問進行合理的管理，可能導致輸出錯誤的模擬量、線程死鎖、軟件假死等問題。

LabVIEW可用的同步機制

在Programming->Synchronization分類下，我們可以看到LabVIEW里可用的同步機制。

同步機制的應用

下面我們用具體的例子來詳細講解一下不同的同步機制。

1）Notifer Operations

上面這個示例，Loop1和Loop2是兩個并行的線程。這是實現(xiàn)多線程的最基本的方法。Loop1負責產(chǎn)生數(shù)據(jù)和停止這兩個線程的運行；Loop2負責讀取Loop1產(chǎn)生的數(shù)據(jù)，并在需要的時候及時終止線程（退出循環(huán)）。它是怎么實現(xiàn)的呢？Loop2等待數(shù)據(jù)通知器發(fā)出通知、等待終止通知器發(fā)出通知，收到通知后把數(shù)據(jù)讀出來或者退出循環(huán)。Loop1則是把數(shù)據(jù)或者退出控件值通過發(fā)送通知傳遞給Loop2。

第一步：Obtain Notifer，獲取通知器，如果不存在則創(chuàng)建。創(chuàng)建時按照初始值進行初始化。

第二步：Send Notification，發(fā)送通知。把數(shù)據(jù)或者控件值通過發(fā)送通知發(fā)送給等待對應通知器的線程。

第三步：Wait on Notification，等待通知。Loop2里調(diào)用Wait on Notification掛起線程，直到收到Loop1發(fā)出的通知后繼續(xù)執(zhí)行。

第四步：Release Notifer，釋放通知器。釋放資源，避免內(nèi)存泄露。 這個示例里Loop1加了100ms的等待，可以確保通過Send Notification發(fā)送出去的數(shù)據(jù)可以被Loop2獲取到。

如果沒有這個等待100ms，Loop1發(fā)送的數(shù)據(jù)是可能丟失的，通知器不會緩沖已經(jīng)發(fā)送的消息，新的消息會覆蓋舊的消息。如果需要緩沖消息（連帶數(shù)據(jù)），可以使用隊列。

關于通知器，我們再看一個VI：Wait on Notification from Multiple，它方便我們等待多個通知，實現(xiàn)多對一的同步。

2）Queue Operations

下面這個代碼，實現(xiàn)的功能和上面Notifier Operations里的例子是一樣的。不同的是這里用的是隊列（Queue）。隊列的特點是先進先出（FIFO）、緩存數(shù)據(jù)。

前面提到過，如果Loop1沒有100ms等待，使用Notifer Operations是可能會丟失數(shù)據(jù)的，但是隊列這里是不會的。哪怕我們?nèi)コ齃oop1里的100ms等待、在Loop2里加上100ms等待，讓數(shù)據(jù)產(chǎn)生的速度大于數(shù)據(jù)被讀取的速度，也是不會導致數(shù)據(jù)丟失的，來不及被讀取的數(shù)據(jù)都會被存儲在隊列里。

隊列不能實現(xiàn)類似Wait on Notification from Multiple的功能。

3）Semaphore

Semaphore，信號量，是一個常見且重要的概念。可以簡單理解為類似紅綠燈（信號燈）的功能。四個方向的車都要過十字路口，十字路口又不能同時過的，它是一個競爭性資源，不同方向的車（線程）對它的使用存在競爭。實際生活中是怎么辦的呢？誰獲得了綠燈（信號量）誰就可以通過。 多個線程訪問競爭性資源前，先嘗試獲取信號量，能夠獲得信號量的線程有權使用競爭性資源，使用完競爭性資源后釋放信號量（單方向綠燈不能一直亮著?。?/p>

此外，對關鍵代碼段（Critical Section）也需要使用信號量進行保護。關鍵代碼段是指涉及變量或競爭性資源訪問的代碼，采用信號量進行管理，以避免多個線程同時修改變量或試圖同時訪問競爭性資源。

4）Rendezvous

Rendezvous，集合點，比較好理解，大家都到集合點后再出發(fā)。

例如下面這個代碼：

第一步，創(chuàng)建集合點。集合點大小為2，表示需要等待兩個任務到達集合點代碼才能往下執(zhí)行。

第二步、第三步，在集合點等待，Wait at Rendezvous。當Loop1和Loop2的數(shù)據(jù)流都到達集合點后，Loop1和Loop2才能夠往下繼續(xù)執(zhí)行。

第四步，銷毀集合點，釋放內(nèi)存。

5）Occurrences

事件發(fā)生（Occurrences），用于在不同代碼位置或不同線程之間同步活動。事件發(fā)生不需要輪詢。 例如以下代碼： 第一步，產(chǎn)生一個事件發(fā)生（Occurrence）。 第二步，Loop2等待第一步產(chǎn)生的Occurrence。這個時候Loop2線程被掛起，只有等待的事件發(fā)生（Occurrence）被Set后這個線程才會繼續(xù)執(zhí)行。 第三步，Loop1在完成其它可能的工作后，Set第一步中產(chǎn)生的事件發(fā)生（Occurrence），以使得所有在等待該Occurrence的線程可以繼續(xù)運行。

6）First Call？、Synchronize Data Flow

First Call？檢查某段代碼或者某個子VI是否是第一次運行。 Synchronize Data Flow用于同步數(shù)據(jù)訪問，它有四個輸入端，并有四個輸出端與輸入端一一對應。只有四個輸入端的數(shù)據(jù)都達到該VI節(jié)點了，代碼才會從該節(jié)點繼續(xù)往下執(zhí)行。 例如下面代碼，當First Call？檢查到該VI是第一次運行時，先等待四個模擬信號數(shù)據(jù)（可以是實際項目中的文件讀取、數(shù)據(jù)采集、系統(tǒng)初始化等工作）都到齊后，再往下執(zhí)行代碼。

所以下面這個測試代碼（ONCE就是上面的VI）里，只會有一個Graph控件會有波形數(shù)據(jù)顯示。另一個Graph控件的ONCE子VI被判斷為非首次執(zhí)行，沒有波形數(shù)據(jù)產(chǎn)生。

使用好這些同步機制可以讓我們設計出可靠的應用軟件。涉及代碼內(nèi)并發(fā)訪問、多線程、競爭性資源使用的，必須采用一定的同步機制，否則軟件一定會有出錯的時候——可能暫時沒發(fā)現(xiàn)，但是隱患一直在。

審核編輯：劉清