昨天在《學(xué)習(xí)LabVIEW（二）——操作.NET泛型類》給出的代碼，實際上是有錯誤的。按照我們的設(shè)想，首先調(diào)用了Add，將Key-Value對“eleven”-11放入了Dictionary中，然后調(diào)用TryGetValue，查找Key: "eleven"對應(yīng)的Value。所以查詢必然應(yīng)該是成功的。然而，反復(fù)執(zhí)行昨天的代碼，偶爾會出現(xiàn)查詢失敗的情況，如下圖所示：


明明已經(jīng)用Add添加了Key: "eleven"，為什么有時候會查詢失敗呢？原因在于我們使用了錯誤的觀念編寫LabVIEW程序。
傳統(tǒng)的計算機語言，本質(zhì)上以指令的流動為核心編寫代碼，寫出來的代碼按照順序被一條一條執(zhí)行。但是像LabVIEW和Simulink這樣的圖形化編程語言，是以數(shù)據(jù)的流動為核心構(gòu)造程序的。當(dāng)程序以數(shù)據(jù)的流動為核心構(gòu)造時，有時指令的執(zhí)行先后順序就不那么明顯了，甚至在不知不覺中一些指令會自動的被并行化執(zhí)行。關(guān)于這一點我曾經(jīng)咨詢過NI的客服，他們曾明確表示過，LabVIEW的運行時內(nèi)部會自動利用多線程來處理可以并行執(zhí)行的函數(shù)，無需用戶的干預(yù)。這是一個非常好的特性，而且也是非常符合圖形化編程這種以數(shù)據(jù)流動和核心的編程方式的特點的。
然而，當(dāng)我們還是帶著以前的以指令為核心編程的觀念畫LabVIEW程序時，就會不知不覺犯下錯誤。昨天寫入和查詢Dictionary的代碼段如下圖所示：


看起來，從左到右執(zhí)行的話，似乎Add是先于TryGetValue的。這實際上是圖形的繪制方式迷惑了我們。如果簡單調(diào)整一下各個節(jié)點的位置，如下圖所示：


以數(shù)據(jù)流動為核心的LabVIEW就不一定會先執(zhí)行哪一個函數(shù)了。如果先執(zhí)行的是TryGetValue，就會出現(xiàn)查詢失敗的情況。
現(xiàn)在應(yīng)該怎么解決這個問題呢？LabVIEW以數(shù)據(jù)流動為核心的編程思想，一方面使自動化的并行編程稱為可能，另一方面，使“順序執(zhí)行”成了一種需要顯示聲明的結(jié)構(gòu)；這與傳統(tǒng)的語言是非常不同的，傳統(tǒng)語言寫代碼，一行一行的碼，一行一行的被執(zhí)行，自然就是順序結(jié)構(gòu)。
我們在工具箱的編程這一欄中找到了用以表示順序結(jié)構(gòu)的工具：


用這個平鋪式順序結(jié)構(gòu)將需要先于TryGetValue調(diào)用的部分框起來，如下圖所示：


這樣一來，只有框內(nèi)所有的動作執(zhí)行完成之后，數(shù)據(jù)才會繼續(xù)往下流動，于是再也沒有出現(xiàn)查詢失敗的情況了。