了解了Channel Wire后，我們來看看關(guān)于Channel Wire的一些應(yīng)用和注意點(diǎn)。?

? 1、Channel Messenger Handler

操作者通過用戶界面上不同的按鈕，把需要不同的消息發(fā)送給消息處理線程；消息處理線程按照接收到消息的先后順序處理這些消息。這也是一個(gè)經(jīng)典的設(shè)計(jì)模式，它的實(shí)現(xiàn)路徑就是messenger類型的channel wire。

注意：上面三個(gè)循環(huán)是并行的三個(gè)線程。channel wire不定義代碼執(zhí)行順序。 這是一個(gè)非常實(shí)用的設(shè)計(jì)模式，可以把需要處理的子任務(wù)做成subVI，在Message Handling Loop里調(diào)用。 2、正確使用stream channel，避免死鎖 這個(gè)示例的名稱是“channel-tag”，演示的功能是A、B、C三個(gè)工作站的溫度一旦超過Threshold Setting設(shè)置的值就顯示“Too hot！”予以警示。

下圖是初始代碼。這個(gè)代碼仔細(xì)看看是存在兩個(gè)bug的。第一，有兩個(gè)寫通道操作（下圖標(biāo)記1和2的兩處），但是執(zhí)行順序不確定。第二，右邊三個(gè)線程可能以threshold的值為0運(yùn)行，因?yàn)樽x通道操作可能未讀到數(shù)據(jù)（右邊三個(gè)線程之一或者全部在通道寫入完成前開始運(yùn)行了）。

針對(duì)上述bug，下圖代碼做了改進(jìn)。 第一，1初特意加了一根連接線，明確兩個(gè)寫通道操作的執(zhí)行順序。第二，通過移位寄存器（2和3）讓讀通道操作第一次執(zhí)行時(shí)無限等待，直到讀到數(shù)據(jù)了再往下執(zhí)行，以確保threshold至少被寫入了一次。

3、準(zhǔn)確理解含有channel wire的程序執(zhí)行順序 Parallel Channels Problem，這個(gè)示例，演示了多個(gè)channel wire并用的時(shí)候，可能出現(xiàn)的死鎖問題。程序界面上有三個(gè)Stop按鈕，有可能可以正常退出這個(gè)程序，也極有可能無法正常退出。常見的結(jié)果應(yīng)該是，A、B、C三部分都停止更新數(shù)據(jù)了，但是主程序無法退出。

出現(xiàn)這個(gè)問題的原因在于通道的Read操作，默認(rèn)是無限等待的——沒有讀到數(shù)據(jù)就一直等待。Producer A停止后，ConsumerA可能無數(shù)據(jù)可讀，就會(huì)一直等下去，從而主程序就無法正常退出。 Producer B和Consumer B通過給Read設(shè)置20ms超時(shí)時(shí)間來解決這個(gè)問題。 Producer C和Consumer C通過Write和Read操作的last element屬性來解決這個(gè)問題。

以上幾個(gè)示例，都是LabVIEW自帶的。LabVIEW里還有很多有關(guān)channel的示例，建議大家去看看，對(duì)開闊思路、加深理解、熟練運(yùn)用channel wire都大有裨益。

編輯：黃飛

?