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


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


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


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


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


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