葛 亮，蔣 炎，張 禾，鄧 勇，肖小汀，薛志波，張嘉偉

(1.西南石油大學機電工程學院，四川成都 610500；2.西南石油大學電氣信息學院，四川成都 610500；3.中海油田服務股份有限公司油田技術研究院，河北三河 065200)

0 引言

傳統(tǒng)的上位機測試系統(tǒng)或應用多采用串行模式，使整個測試系統(tǒng)或者應用在使用當中只能執(zhí)行當前正在執(zhí)行的操作，而無法同時響應用戶的其他操作。當執(zhí)行周期過長時，應用程序相當于被掛起，在用戶看來應用程序好像出現(xiàn)卡頓或死機現(xiàn)象，只有當整個應用程序內(nèi)的所有事件、所有子程序完全被執(zhí)行完后，應用程序的線程才能空閑下來，用戶才能對該應用執(zhí)行其他操作。但是，這對調(diào)度任務特別復雜或者測試周期長的應用程序來說是無法接受的。因此，優(yōu)化測試模式、提高測試效率是十分必要的。

針對串行模式周期時延和調(diào)度問題，2012年，吳忠鍇、梁志劍、馬鐵華等學者在研究“力學實驗數(shù)據(jù)采集系統(tǒng)軟件”時采用生產(chǎn)者/消費者模式[1-3]來避免數(shù)據(jù)采集周期與數(shù)據(jù)處理周期不一致造成的數(shù)據(jù)丟失或數(shù)據(jù)重復利用的問題[4]。2020年，為了滿足汽車穩(wěn)定控制系統(tǒng)(ESC)電子控制單元多個產(chǎn)品同步執(zhí)行測試的需要，劉規(guī)劃對多線程以及并行測試技術進行了研究，開發(fā)了基于LabVIEW和TestStand的汽車ESC產(chǎn)品并行測試系統(tǒng)，解決了多線程軟件編程中遇到的競爭、資源沖突、死鎖等問題[5]。2001年，文獻[6]在傳統(tǒng)的測試結(jié)構(gòu)的基礎上對并行架構(gòu)和網(wǎng)絡技術做出詳細的理論研究，尤其是其中的分布式系統(tǒng)概念、遠程測量、共享數(shù)據(jù)等并行技術和多線程技術方面。2017年，文獻[7]利用LabWindows/CVI研究了“一種通過USB線連接PC機的液晶眼睛控制器”，該控制器的軟件部分采用多線程技術與儀器進行數(shù)據(jù)交互，使得在廉價而多功能的醫(yī)療儀器中實現(xiàn)高效的算法成為可能。

通過研究發(fā)現(xiàn)，多數(shù)學者在傳統(tǒng)測試模式出現(xiàn)問題的基礎上提出了許多研究思路，這加速了并行技術[8-14]、多線程技術[15-19]在工控測量行業(yè)中的發(fā)展。但這些研究在成型的測試框架和多線程優(yōu)化模型上還存在不足，系統(tǒng)性不強。

本研究根據(jù)現(xiàn)代具有多核心和多線程微處理器的計算機技術體系，以核磁測井項目為例對多線程優(yōu)化機理進行研究，建立核磁測井儀器的多線程優(yōu)化模型，開發(fā)出高溫多維核磁測井儀器軟件(EMRT2.0)，并與一維核磁測井儀器軟件(EMRT1.0)進行對比試驗測試。該多線程優(yōu)化模型應用多線程技術和并行測試技術，將CPU資源利用到最佳。

1 LabVIEW多線程優(yōu)化機理

1.1 編程環(huán)境介紹

LabVIEW是自動多線程的編程語言，如果VI的代碼并行執(zhí)行，LabVIEW就將它們分配在多個執(zhí)行線程內(nèi)同時運行。一般情況下，運行一個 VI，LabVIEW 至少會開辟2個線程：一個界面線程(UI Thread)，用于處理界面刷新，用戶對控件的操作等；一個執(zhí)行線程，負責VI除界面操作之外的其他工作[20-21]。

在并行執(zhí)行時,LabVIEW 會自動將測試任務安排在不同線程下同時運行，以提高程序的執(zhí)行速度，節(jié)省程序的運行時間。今后多核計算機將成為主流配置，多線程的優(yōu)勢會更為明顯。

1.2 常用優(yōu)化機制

從內(nèi)部來看，在LabVIEW的編程環(huán)境中，常用的優(yōu)化機制有局部變量、全局變量、節(jié)點、引用及隊列等。這幾類優(yōu)化機制對計算機硬件資源配置的要求和消耗各不相同，為了更好地實現(xiàn)多線程優(yōu)化模型的優(yōu)化和對CPU資源的利用達到最優(yōu)，需要合理使用這些常用優(yōu)化機制。

(1)局部變量。局部變量的使用范圍被限制在一定區(qū)域，其定義和使用效果與C語言相同。局部變量必須有與之對應的控件，一個控件可以有一個或多個局部變量。局部變量的作用是在局部區(qū)域內(nèi)傳值，可以作為輸入也可以作為輸出。每個局部變量都需要復制控件內(nèi)的數(shù)據(jù)，進而導致消耗更多的內(nèi)存。

(2)全局變量。全局變量的功能與局部變量類似，不同在于全局變量的作用范圍更廣，可以做到跨線程和跨VI。同樣，局部變量潛藏的問題，全局變量也具備。

(3)節(jié)點。節(jié)點在LabVIEW中使用非常普遍。節(jié)點用于訪問控件的屬性和方法。但節(jié)點的執(zhí)行效率較低，甚至低于全局變量。

(4)引用。引用通常與節(jié)點配合使用，將控件的屬性和方法綁定在類中。引用使程序得到簡化并減少節(jié)點和局部變量的使用。

(5)隊列。隊列狀態(tài)機把將要執(zhí)行的狀態(tài)編排入隊，隊列中的狀態(tài)名與狀態(tài)機的各狀態(tài)一一對應，用來控制狀態(tài)的轉(zhuǎn)換順序。執(zhí)行過的狀態(tài)，其狀態(tài)名將從隊列中刪除，同時根據(jù)運行狀態(tài)和觸發(fā)事件，新的狀態(tài)名將會被添加到隊列中。在數(shù)據(jù)傳遞過程中，隊列是LabVIEW處理線程間數(shù)據(jù)傳遞的主要方法，它需要嚴格設置隊列名稱和隊列數(shù)據(jù)傳遞類型。

2 多線程優(yōu)化模型

2.1 多線程技術原理

從計算機的角度來講，可以將多線程技術理解成CPU在時間軸上做了一個時間分割，將時間分割成不同長度的時間片。每個線程被分配不同的時間片，而每個時間片又含有各自獨立的堆棧和CPU寄存器狀態(tài)，同時在每個時間片內(nèi)又將執(zhí)行相應的任務。當任務結(jié)束后，優(yōu)先級次高的線程將被創(chuàng)建和執(zhí)行。在某個時刻，CPU僅執(zhí)行某一個時間片內(nèi)的線程[22]。從處理速度上分析，CPU切割的時間片極其短暫，肉眼無法分辨，使得多個線程看起來是在同時運行[23]。

2.2 模型構(gòu)建

在實際應用中，由于硬件資源有限，單個硬件資源配合上位機測試系統(tǒng)使用不存在資源調(diào)度，而多個硬件資源或多個測試模式配合上位機測試系統(tǒng)使用存在資源調(diào)度。資源調(diào)度是在不沖突的情況下，有序地完成單個測試模式對硬件資源的啟用和釋放的過程。它分為2種。第一種，上位機測試系統(tǒng)通過調(diào)度多個硬件資源，使系統(tǒng)內(nèi)每個硬件資源在某個時間片內(nèi)得到運行。第二種，上位機測試系統(tǒng)針對單個硬件資源開發(fā)多個測試模式，每個測試模式在不同的時間節(jié)點去調(diào)用該硬件資源。

本研究的核磁測井儀器的多線程優(yōu)化模型根據(jù)第二種方式提出。在綜合常用優(yōu)化機制的基礎上，選擇采用隊列和引用的方式來構(gòu)建多線程優(yōu)化模型，對同一個核磁測井儀器做不同的功能測試。整個多線程優(yōu)化模型由圖1和圖2組成，圖2為圖1中主線程和副線程的優(yōu)化框架模型，主、副線程采用相同的優(yōu)化框架模型。

圖1 核磁測井儀器多線程資源調(diào)度模型圖

圖2 核磁測井儀器多線程優(yōu)化框架模型圖

如圖1和圖2所示，該多線程優(yōu)化模型內(nèi)部做出以下優(yōu)化。

(1)線程劃分。多線程優(yōu)化模型內(nèi)部被分解成主線程、副線程、隊列線程。這3種線程再次細分成數(shù)據(jù)采集、數(shù)據(jù)傳輸、數(shù)據(jù)處理、數(shù)據(jù)顯示、數(shù)據(jù)存儲、數(shù)據(jù)回放等輔助線程。線程劃分的方式使測試任務和資源調(diào)度更為便捷。

(2)模式調(diào)整。多線程優(yōu)化模型將EMRT1.0的串行模式調(diào)整為并行模式，即EMRT2.0的主線程與副線程能夠并行運行。并行測試方式使EMRT2.0能夠解決EMRT1.0周期時延問題。

(3)數(shù)據(jù)處理方式改進。多線程優(yōu)化模型將EMRT1.0調(diào)用MATLAB腳本的方式改進為調(diào)用MATLAB生成程序集的方式來實現(xiàn)孔隙度功能；這種方式解決了EMRT1.0調(diào)用腳本時依賴MATLAB開發(fā)平臺的問題并增加程序的移植性。

(4)類封裝傳值。多線程優(yōu)化模型對控件進行類封裝，即控件的屬性和方法通過類封裝后進行傳遞。類封裝方式優(yōu)化了整個控制臺的代碼，避免當EMRT2.0隨著功能復雜化后需要增加CPU的負荷來保存程序代碼而耗費大量時間的問題，避免EMRT2.0頻繁復制和刷新控件內(nèi)的值。

(5)簇封裝。多線程優(yōu)化模型將EMRT2.0界面控件通過簇進行封裝。簇封裝方式為控制臺和前端界面節(jié)省更多空白空間，便于維護和閱讀。

2.3 模型分析

如圖1所示，上位機由主線程、隊列線程、副線程構(gòu)成。這3個線程內(nèi)部由相應的輔助線程組成，輔助線程在上述3個線程被創(chuàng)建后由軟件開發(fā)平臺內(nèi)部自行創(chuàng)建。主線程和副線程都設置有固定時間去輪詢來自隊列線程的消息，即線程內(nèi)部每間隔固定的時間將會去執(zhí)行如圖2所示的IDLE部分。IDLE部分是主、副線程較為重要的設置部分，它在超時的情況下將線程消息或Debug內(nèi)的消息送入隊列。經(jīng)過試驗驗證，主、副線程的超時設置必須大于0，否則隨著EMRT2.0啟動，計算機的CPU占用率會飆升至90%以上而正常情況下僅為1%。下位機由核磁測井儀器構(gòu)成。

2.3.1 事件觸發(fā)線程

(1)用戶事件觸發(fā)線程。用戶事件是由用戶通過點擊前端界面控件從而產(chǎn)生一系列的響應事件，該線程的啟用和銷毀具有隨機性。

(2)數(shù)據(jù)事件觸發(fā)線程。數(shù)據(jù)事件觸發(fā)線程的啟用由以下過程完成觸發(fā)。當副線程完成一周期的數(shù)據(jù)采集后，隊列線程將數(shù)據(jù)傳送至圖2中主線程的線程消息部分，然后由進入IDLE部分的新增消息去啟用數(shù)據(jù)處理線程和數(shù)據(jù)顯示線程。從線程耗時角度分析，數(shù)據(jù)采集線程與數(shù)據(jù)處理線程在整個測試周期內(nèi)耗時最長。

如圖3所示，若采用串行模式，當前周期需要等待數(shù)據(jù)處理完成后才能進行下周期的數(shù)據(jù)采集。當數(shù)據(jù)處理耗時過長時，串行模式會影響到下周期的數(shù)據(jù)采集，這相當于整個周期被強制延長。

圖3 數(shù)據(jù)采集與處理關系圖

如果采用并行模式，副線程負責數(shù)據(jù)采集，主線程負責數(shù)據(jù)處理。由于2個線程的相關性較低，即使數(shù)據(jù)處理耗損時間稍長也并不阻礙副線程的數(shù)據(jù)采集。這表明前一次的數(shù)據(jù)處理和后一次的數(shù)據(jù)采集是否同時進行取決于前一次數(shù)據(jù)處理的復雜程度。

2.3.2 數(shù)據(jù)分析處理線程

2.3.2.1 數(shù)據(jù)處理線程

數(shù)據(jù)處理線程的啟用是由圖2中主線程的“線程消息”入列后再觸發(fā)。隊列中的數(shù)據(jù)屬于原始數(shù)據(jù)。原始數(shù)據(jù)包含隊列名、隊列命令、采集數(shù)據(jù)、選擇枚舉以及計數(shù)器，其中計數(shù)器僅存在于主線程，副線程不含計數(shù)器。另外，在整個采集過程中，EMRT2.0需要將數(shù)據(jù)移位緩沖在臨時緩沖區(qū)域內(nèi)，而且?guī)缀跛胁杉臄?shù)據(jù)都需要臨時緩存。因此，為了優(yōu)化EMRT2.0的數(shù)據(jù)處理部分，在數(shù)據(jù)處理線程中做出以下優(yōu)化。

第一，為了減少LabVIEW在VI運行狀態(tài)下對內(nèi)存資源的消耗，EMRT2.0的前面板摒棄使用較大的數(shù)組和層次化數(shù)據(jù)結(jié)構(gòu)。因為LabVIEW對這類數(shù)據(jù)需要建立較大的緩沖區(qū)，這導致LabVIEW無法快速處理此類結(jié)構(gòu)，占用更多內(nèi)存。

第二，由于LabVIEW開發(fā)平臺自身不能進行縮放，進而導致程序布局隨著功能復雜后變得冗雜，無論是代碼維護還是項目對接都將變成棘手的問題。EMRT2.0采用子VI的方式來避免這類問題。

第三，利用第三方軟件對復雜算法進行封裝。例如，在數(shù)據(jù)處理線程中會加載經(jīng)過Visual C++編譯的T2反演庫和MATLAB編譯的.Net程序集。從軟件的側(cè)重點上來講，這符合多線程優(yōu)化模型的優(yōu)化思想，開發(fā)平臺選擇開發(fā)周期短的LabVIEW,重量級算法選擇MATLAB和Visual C++，從而提高EMRT2.0的可移植度。

2.3.2.2 數(shù)據(jù)顯示線程

數(shù)據(jù)顯示線程的啟用由以下過程觸發(fā)。當圖1中的原始數(shù)據(jù)完成數(shù)據(jù)處理后，由圖2中的“下一條入列消息”將經(jīng)過數(shù)據(jù)處理后存入臨時緩沖區(qū)內(nèi)的采集數(shù)據(jù)送至數(shù)據(jù)顯示線程進行顯示和刷新。為了優(yōu)化數(shù)據(jù)顯示線程，根據(jù)多線程優(yōu)化模型的優(yōu)化思想?？刂婆_和前端界面的控件采用簇的方式進行捆綁，控制臺中的控件盡可能直接與子VI相連接。捆綁方式減少代碼的過度暴露，增大面板預留空間，增強代碼可讀性。

2.3.2.3 數(shù)據(jù)存儲線程

數(shù)據(jù)存儲線程的啟用是在圖1中由用戶觸發(fā)界面控件后產(chǎn)生。本研究提到的數(shù)據(jù)存儲線程不僅用于儲存測試數(shù)據(jù)，該線程還用于讀取配置數(shù)據(jù)。

一方面，隨著功能復雜化后，每個測試模式都需要單獨創(chuàng)建配置表信息。從EMRT2.0的測試邏輯來看，一次完整且連續(xù)的數(shù)據(jù)采集需要對核磁測井儀器做出準確的配置。因此，主線程中的數(shù)據(jù)存儲線程需要將用戶操作的最新界面配置表信息存入ACCESS數(shù)據(jù)庫，而副線程的數(shù)據(jù)存儲線程需要從ACCESS數(shù)據(jù)庫讀取最新的配置表信息來配合副線程中的數(shù)據(jù)采集線程使用。為了優(yōu)化配置信息，根據(jù)多線程優(yōu)化模型的優(yōu)化思想，將配置信息寫入ACCESS數(shù)據(jù)庫和從ACCESS數(shù)據(jù)庫讀取配置信息都被封裝成子VI并留有枚舉選擇框，其中枚舉選擇框?qū)袦y試模式的配置信息表。此外，對于ACCESS數(shù)據(jù)庫，該數(shù)據(jù)庫屬于輕量級數(shù)據(jù)庫，功能強大且移植性強，用戶可以不依賴服務器就能訪問數(shù)據(jù)庫。重要的是，ACCESS數(shù)據(jù)庫能夠脫離OFFICE環(huán)境，適合移植。

另一方面，由于測試模式的原始數(shù)據(jù)長度范圍在500字節(jié)～70 000萬字節(jié)之間，因此測試數(shù)據(jù)選擇含有逗號分隔符的CSV文件進行存儲。該格式文件有2個優(yōu)點：第一，利用LabVIEW自帶的含有格式限制的讀取函數(shù)，可以一次快速讀取到程序中；第二，CSV文件屬于文本文件，對存儲沒有行限制，相較于其他EXECL格式文件具有更小的體積，有利于測試數(shù)據(jù)進行存儲操作。

2.3.2.4 數(shù)據(jù)回放線程

數(shù)據(jù)回放線程的啟用是在圖1中由用戶觸發(fā)界面控件后產(chǎn)生。該線程便于用戶查詢過去的測試信息和錯誤日志，有利于檢查核磁測井儀器出現(xiàn)的各種問題。從EMRT2.0測試邏輯的角度進行分析，數(shù)據(jù)回放操作只在主線程進行，該線程將過去存入數(shù)據(jù)庫和CSV文件中的歷史數(shù)據(jù)提取到主線程，并由主線程開啟數(shù)據(jù)處理和數(shù)據(jù)顯示線程來完成數(shù)據(jù)回放操作。

2.3.3 隊列線程

隊列線程的本質(zhì)是隊列技術[24]。隊列線程在EMRT2.0中負責跨線程和跨VI傳輸命令和數(shù)據(jù)，起到中間橋梁的作用。如圖1和圖2所示，主線程和副線程通過隊列銜接。主線程負責發(fā)送采集命令和送數(shù)命令給副線程，而副線程負責發(fā)送原始數(shù)據(jù)和少量資源調(diào)度命令給主線程?？梢钥闯?，在隊列的銜接下，主、副線程采用并行測試技術和多線程技術獨立運行在相應的線程，互不干擾，極大提高了測試效率。

2.3.4 副線程

如圖1和圖2所示，EMRT2.0將所有的測試模式單獨劃分成副線程，副線程主要負責數(shù)據(jù)采集任務。在循環(huán)周期內(nèi)，主線程負責通過隊列線程將命令送至副線程，副線程負責與核磁測井儀器通過USB協(xié)議進行數(shù)據(jù)交互，原始數(shù)據(jù)通過隊列線程傳送到主線程。

2.4 模型實現(xiàn)

前文詳細介紹了多線程優(yōu)化模型的模型構(gòu)建和模型分析部分，對EMRT2.0的實現(xiàn)奠定理論基礎。本節(jié)基于多線程優(yōu)化模型設計的EMRT2.0項目模型如圖4所示，EMRT2.0項目實物如圖5所示，EMRT2.0界面實物如圖6所示，EMRT2.0框架實物如圖7所示。

圖4 EMRT2.0項目模型圖

圖5 EMRT2.0項目實物圖

圖6 EMRT2.0界面實物圖

如圖4和圖5所示，整個模型實例分為01_Main、02_IC、03_CPGM、04_DECPGM四大板塊。項目模型和實物完全吻合，4個儀器標定模式和18個測井模式，共22個測試模式。所有的測試模式被劃分為副線程，負責數(shù)據(jù)采集任務，可以看出，副線程與主線程采用相同的框架，都包含有00_Class、01_Frame、02_SubVI、03_Queue、04_State、05_ErrorState、06_Debug、07_Configure、08_File 8部分。00_Class將測試模式和框架本身含有的參數(shù)封裝在類中,負責綁定方法和屬性；01_Frame包含如圖7所示的5個線程框架VI，從左到右分別為Create、Update、Idle、Retrieve、Delete，負責04_State中各種線程消息的循環(huán)；在主線程中，02_SubVI包含大量的數(shù)據(jù)處理VI和配置VI，負責數(shù)據(jù)處理和初始化；03_Queue包含隊列VI，負責承載隊列消息；05_ErrorState負責記錄測試的錯誤日志和執(zhí)行錯誤處理；06_Dubug負責手動調(diào)試線程；07_Confiure負責保存大量配置文件和測試數(shù)據(jù)，如LabVIEW調(diào)用ftd2xx.dll[25-26]動態(tài)庫去執(zhí)行USB通訊的各種子VI、T2反演動態(tài)鏈接庫以及孔隙度算法庫等；08_File為預留線程文件空間。

圖7 EMRT2.0框架實物圖

3 多線程優(yōu)化測試

核磁測井儀器測井模式圖如圖8所示，圖中有4個儀器標定模式和18個測井模式，EMRT1.0包含4個儀器標定模式和前8個CPMG測井模式，EMRT2.0包含全部測試模式。從實驗結(jié)果的角度出發(fā)，EMRT2.0在EMRT1.0的基礎上增加了測井模式和更改了命令參數(shù)，且本研究只需驗證多線程優(yōu)化模型。因此，前面所述的問題并不影響實驗效果，兩個版本的測試軟件只需保證對比的測試模式相同即可。

圖8 核磁測井儀器測井模式圖

3.1 實驗條件

為了讓實驗更具有對比性，表1的計算機硬件配置屬性嚴格低于表2。

表1 實驗條件1

表2 實驗條件2

3.2 實驗結(jié)果

表3和表4分別為實驗條件1和2的測試結(jié)果。

表3和表4中所涉及的“×”表示不存在或無嚴格設定標準，例如表3中版本1.0的掃頻模式對應的調(diào)度模式表示EMRT1.0為串行模式，沒有進行嚴格的線程劃分，故不存在調(diào)度時間。表3和表4中所測試的調(diào)度時間、采集時間、傳輸時間、處理時間、CPU占用率以及內(nèi)存占用均是平均值。通過上述兩表所測試的優(yōu)化指標數(shù)據(jù)，可以得到以下信息：

(1)整體對比表3和表4，當硬件資源的配置屬性得到提升后，EMRT1.0與EMRT2.0的各項指標得到大幅度提高。

(2)對比表3和表4的測試數(shù)據(jù)，1.0版本下FBW2F模式的設定周期為3 s，實際周期為4～6 s，而2.0版本FBW2F模式的設定周期為3 s，實際周期為2～3 s。因此，可以看出EMTR2.0的實際周期低于設定周期并在EMRT1.0的基礎上將測試周期縮短為原來的1/2。

(3)對比表3和表4中1.0版本的測試數(shù)據(jù)，MATLAB的CPU占用高達85%(表3)、60%(表4)以上。

(4)對比表3和表4中1.0版本和2.0版本的測試數(shù)據(jù)，EMRT2.0在EMRT1.0的基礎上脫離了MATLAB開發(fā)平臺，不再占用計算機的CPU資源和消耗計算機的物理內(nèi)存；此外，EMRT2.0的儀器標定模式和測井模式的物理內(nèi)存與CPU分別達到406.9～585.2 MB(表3)、372.4～537.0 MB(表4)和4.0%～62.0%(表3)、1.4%～6.2%(表4)，而EMRT1.0與之對應的僅為155.4～177.3 MB(表3)、144.5～145.3 MB(表4)和3.0%～12.0%(表3)、0.4%～1.5%(表4)，這是由于EMRT2.0在原有模式上增加了10個測井模式和孔隙度算法功能。不難發(fā)現(xiàn)，EMRT2.0增加功能的同時，充分利用了計算機的資源，這說明EMRT2.0整體提升了測試性能并優(yōu)化了資源調(diào)度。

表3 實驗條件1測試結(jié)果

表4 實驗條件2測試結(jié)果

4 結(jié)論

本研究對核磁測井儀器的多線程優(yōu)化模型進行研究，并通過模型構(gòu)建、模型分析、模型實現(xiàn)以及對比試驗測試驗證了多線程優(yōu)化模型的可行性與有效性。本研究的主要內(nèi)容如下：

(1)基于LabVIEW編程環(huán)境與優(yōu)化機理，結(jié)合多線程技術和并行測試技術，建立核磁測井儀器的多線程優(yōu)化模型。

(2)基于多線程優(yōu)化模型對核磁測井儀器的資源調(diào)度和多線程功能與關系進行分析，能夠滿足多任務調(diào)度測試和并行技術需要。

(3)基于多線程優(yōu)化模型開發(fā)出EMRT2.0并選用測試周期、CPU、物理內(nèi)存作為評價指標。通過表4中EMRT2.0與EMRT1.0的部分模式對比試驗可知，EMRT2.0的實際測試周期縮短為EMRT1.0的實際測試周期的1/2，CPU的利用率從0.4%～1.5%提升至1.4%～6.2%，MATLAB的CPU利用率和物理內(nèi)存占用降至0。

本研究驗證了核磁測井儀器多線程優(yōu)化模型的正確性，對資源調(diào)度、串行模式的周期試驗、線程間大數(shù)據(jù)傳輸、資源沖突、程序移植等方面具有指導意義。