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

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

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

如果不對(duì)這個(gè)模擬輸出通道的訪問(wèn)進(jìn)行合理的管理，可能導(dǎo)致輸出錯(cuò)誤的模擬量、線程死鎖、軟件假死等問(wèn)題。

LabVIEW可用的同步機(jī)制

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

同步機(jī)制的應(yīng)用

下面我們用具體的例子來(lái)詳細(xì)講解一下不同的同步機(jī)制。

1）Notifer Operations

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

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

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

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

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

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

關(guān)于通知器，我們?cè)倏匆粋€(gè)VI：Wait on Notification from Multiple，它方便我們等待多個(gè)通知，實(shí)現(xiàn)多對(duì)一的同步。

2）Queue Operations

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

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

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

3）Semaphore

Semaphore，信號(hào)量，是一個(gè)常見(jiàn)且重要的概念?？梢院?jiǎn)單理解為類似紅綠燈（信號(hào)燈）的功能。四個(gè)方向的車都要過(guò)十字路口，十字路口又不能同時(shí)過(guò)的，它是一個(gè)競(jìng)爭(zhēng)性資源，不同方向的車（線程）對(duì)它的使用存在競(jìng)爭(zhēng)。實(shí)際生活中是怎么辦的呢？誰(shuí)獲得了綠燈（信號(hào)量）誰(shuí)就可以通過(guò)。 多個(gè)線程訪問(wèn)競(jìng)爭(zhēng)性資源前，先嘗試獲取信號(hào)量，能夠獲得信號(hào)量的線程有權(quán)使用競(jìng)爭(zhēng)性資源，使用完競(jìng)爭(zhēng)性資源后釋放信號(hào)量（單方向綠燈不能一直亮著?。?。

此外，對(duì)關(guān)鍵代碼段（Critical Section）也需要使用信號(hào)量進(jìn)行保護(hù)。關(guān)鍵代碼段是指涉及變量或競(jìng)爭(zhēng)性資源訪問(wèn)的代碼，采用信號(hào)量進(jìn)行管理，以避免多個(gè)線程同時(shí)修改變量或試圖同時(shí)訪問(wèn)競(jìng)爭(zhēng)性資源。

4）Rendezvous

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

例如下面這個(gè)代碼：

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

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

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

5）Occurrences

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

6）First Call？、Synchronize Data Flow

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

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

使用好這些同步機(jī)制可以讓我們?cè)O(shè)計(jì)出可靠的應(yīng)用軟件。涉及代碼內(nèi)并發(fā)訪問(wèn)、多線程、競(jìng)爭(zhēng)性資源使用的，必須采用一定的同步機(jī)制，否則軟件一定會(huì)有出錯(cuò)的時(shí)候——可能暫時(shí)沒(méi)發(fā)現(xiàn)，但是隱患一直在。

審核編輯：劉清