61.LabVIEW-程序中的線程-4-動態(tài)連接庫函數(shù)的線程

61.LabVIEW-程序中的線程-4---動態(tài)連接庫函數(shù)的線程61.LabVIEW-程序中的線程-4---動態(tài)連接庫函數(shù)的線程61.LabVIEW-程序中的線程-4---動態(tài)連接庫函數(shù)的線程61.LabVIEW-程序中的線程-4---動態(tài)連接庫函數(shù)的線程編制僅供參考審核批準生效日期地址：電話：傳真:郵編:LabVIEW程序中的線程4-動態(tài)連接庫函數(shù)的線程四、動態(tài)連接庫函數(shù)的線程1.CLN中的線程設(shè)置LabVIEW可以通過CLN(CallLibraryFunctionNode)節(jié)點來調(diào)用動態(tài)連接庫中的函數(shù)，在Windows下就是指.DLL文件中的函數(shù)。用戶可以通過CLN節(jié)點的配置面板來指定被調(diào)用函數(shù)運行所在的線程。相對于VI的線程配置，CLN的線程選項非常簡單，只有兩項：界面線程(RuninUIthread)和可重入方式(reentrant)。(新版本LabVIEW把這里的reentrant改為Runinanythread了)圖1：在CLN的配置面板上選擇函數(shù)運行的線程在LabVIEW的程序框圖上直接就可以看出一個CLN節(jié)點是選用的什么線程。如果是在界面線程，則節(jié)點顏色是較深的橘紅色的;如果是可重入方式的，則節(jié)點是比較淡的黃色。圖2：不同顏色表示CLN不同的線程設(shè)置2.如何選擇合適的線程對于在CLN中選取何種線程，有一個簡單的判斷方法。如果你要使用的動態(tài)連接庫是多線程安全的，就選擇可重入方式;否則，動態(tài)連接庫不是多線程安全的，就選擇界面線程方式。判斷一個動態(tài)連接庫是不是線程安全的，也比較麻煩。如果這個動態(tài)連接庫文檔中沒用明確說明它是多線程安全的，那么就要當他是非線性安全的;如果能看到動態(tài)連接庫的源代碼，代碼中存在全局變量、靜態(tài)變量或者代碼中看不到有l(wèi)ock一類的操作，這個動態(tài)連接庫也就肯定不是多線程安全的。選擇了可重入方式，LabVIEW會在最方便的線程內(nèi)運行動態(tài)連接庫函數(shù)，一般會與調(diào)用它的VI運行在同一個線程內(nèi)。因為LabVIEW是自動多線程的語言，它也很可能會把動態(tài)連接庫函數(shù)分配一個單獨的線程運行。如果程序中存在沒有直接或間接先后關(guān)系的兩個CLN節(jié)點，LabVIEW很可能會同時在不同的線程內(nèi)運行它們所調(diào)用的函數(shù)，也許是同一函數(shù)。對于非多線程安全的動態(tài)連接庫，這是很危險的操作。很容易引起數(shù)據(jù)混亂，甚至是程序崩潰。選擇界面線程方式：因為LabVIEW只有一個界面線程，所以如果所有的CLN設(shè)置都是界面線程，那么就可以保證這些CLN調(diào)用的函數(shù)肯定全部都運行在同一線程下，肯定不會被同時調(diào)用。對于非多線程安全的動態(tài)連接庫，這就保證了它的安全。3.與VI的線程選項相配合如果你的程序中大量頻繁的調(diào)用了動態(tài)連接庫函數(shù)，那么效率就是一個非常值得注意的問題了。我曾經(jīng)編寫過一個在LabVIEW中使用OpenGL的演示程序(為了演示我們開發(fā)的“ImportSharedLibrary功能”)，對OpenGL的調(diào)用全部是通過CLN方式完成的。由于OpenGL的全部操作必需在同一線程內(nèi)完成，我把所有的CLN都設(shè)置為在界面線程運行的方式。對VI的線程選項沒有修改，還是默認的選項。結(jié)果程序運行極慢，每秒鐘只能刷新一幀圖像，CPU占用100%。但是作為動畫每秒至少25幀才能看著比較流暢。我開始試圖用LabVIEW的profile工具來查找效率低下的VI，結(jié)果居然查找不到。在ProfilePerformanceandMemory工具上顯示的CPU占用時間只有一點點。這個工具竟然顯示不出程序中最耗時的操作在哪里，自然我也對如何優(yōu)化這個程序無從下手了。后來這個演示程序被擱置了一段時間。直到有一天我從同事給我的提供的一些信息中得到了啟發(fā)，才突然想通，這些CPU全部被消耗在線程切換中了。我們調(diào)用OpenGL方法是為每個OpenGLAPI函數(shù)包裝一個APIVI，這些APIVI非常簡單，程序框圖就只有一個CLN節(jié)點，調(diào)用相應(yīng)的OpenGL函數(shù)。由于每個VI都是在默認的執(zhí)行線程中運行，而CLN調(diào)用的函數(shù)卻是在界面線程下運行的。所以每次執(zhí)行一次這樣的APIVI，LabVIEW都要做兩次線程切換，從執(zhí)行線程切換到界面線程，執(zhí)行完函數(shù)，在切換回執(zhí)行線程。線程切換是比較耗時的。我的演示程序刷新一幀要調(diào)用大約兩千次OpenGLAPIVI，總耗時接近一秒。解決這個問題，要么把所有APIVI中的CLN都改為可重入方式，但編寫程序時要保證所有被調(diào)用的函數(shù)都運行在同一線程內(nèi)，這比較困難。比較容易實現(xiàn)的是，把程序中對OpenGL操作相關(guān)的VI也全部都設(shè)置為在界面線程下運行。我選擇的就是后一種方法。改進后的程序，每秒鐘畫30幀圖像也不會占滿CPU。由此，我也想通了另一個問題。就是我曾經(jīng)發(fā)現(xiàn)調(diào)用WindowsAPI函數(shù)遇到的錯誤信息丟失的問題。在調(diào)用某一WindowsAPI函數(shù)返回值為0時，表示有錯誤發(fā)生了。這時你可以調(diào)用GetLastErr和FormatMessage得到錯誤代碼和信息。但是我經(jīng)常遇到的問題是：前一個函數(shù)明明返回值為0，但是隨后調(diào)用的GetLastErr函數(shù)卻無法查到錯誤代碼。我想這一定是看上去兩