何 鋒，曾 文，王秉鈞

酒泉衛(wèi)星發(fā)射中心，甘肅 酒泉 732750

1 引言

近年來隨著國際信息安全形勢問題的日益突出，各國都紛紛立足于開源軟件平臺(tái)，設(shè)計(jì)開發(fā)自主、可控的軟件系統(tǒng)。致力于開發(fā)跨平臺(tái)面向?qū)ο蟮腝t平臺(tái)自誕生以來，經(jīng)過開源社區(qū)的共同努力，已集成了各式各樣的圖形組件和豐富的基礎(chǔ)庫，實(shí)現(xiàn)了對(duì)Windows、IOS、Android、Unix Like 等操作系統(tǒng)的支持，已成為跨平臺(tái)自主軟件首選的開發(fā)工具。OpenMP 即Open Multiprocessing[1]，是基于共享內(nèi)存的一種便攜式和可擴(kuò)展的并行編程模型，包含編譯制導(dǎo)語句、運(yùn)行時(shí)函數(shù)庫和環(huán)境變量三部分，由一組支持C++/Fortran 的應(yīng)用程序接口（API）構(gòu)成，不僅支持細(xì)粒度的for 循環(huán)展開并行，也支持SPMD[2]模式的線程級(jí)別并行。在目前的共享內(nèi)存并行編程標(biāo)準(zhǔn)中，OpenMP是使用最為廣泛和便捷的開發(fā)標(biāo)準(zhǔn)之一，Qt平臺(tái)也提供了對(duì)OpenMP線程庫的支持。

實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)就是要把各類測控設(shè)備如光學(xué)、雷達(dá)、遙測、計(jì)算機(jī)等產(chǎn)生的實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)起來，供事后數(shù)據(jù)分析使用。由于實(shí)時(shí)測控?cái)?shù)據(jù)處理的復(fù)雜性，實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)不但要應(yīng)對(duì)多設(shè)備、高并發(fā)性、大數(shù)據(jù)量的數(shù)據(jù)特點(diǎn)，還要對(duì)異常數(shù)據(jù)有相應(yīng)的處理策略，做到不缺不漏，實(shí)現(xiàn)高可靠性和強(qiáng)容錯(cuò)性。隨著計(jì)算機(jī)硬件的不斷發(fā)展，目前存儲(chǔ)服務(wù)器大多都是單機(jī)多核環(huán)境[3]，但是傳統(tǒng)的串行程序邏輯不能充分利用多核的優(yōu)勢，計(jì)算負(fù)載大多集中在一個(gè)處理核心上，導(dǎo)致計(jì)算資源利用率低，同時(shí)也難以發(fā)揮存儲(chǔ)系統(tǒng)后臺(tái)RAID（Redundant Array of Independent Disks）陣列并行讀寫的優(yōu)勢[4]，存儲(chǔ)效率低，難以滿足日益增長的強(qiáng)實(shí)時(shí)、大流量和可擴(kuò)展的實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)需求。需要設(shè)計(jì)實(shí)現(xiàn)一個(gè)規(guī)?？蓴U(kuò)展、實(shí)時(shí)性高、并行能力強(qiáng)的并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)。

2 總體框架設(shè)計(jì)

實(shí)時(shí)測控?cái)?shù)據(jù)處理系統(tǒng)為了保證系統(tǒng)的強(qiáng)實(shí)時(shí)性，應(yīng)對(duì)一對(duì)多的傳輸要求，大多采用UDP組播協(xié)議，來減輕網(wǎng)絡(luò)壓力[5]。本文設(shè)計(jì)的系統(tǒng)基于Qt 圖形界面使用OpenMP 實(shí)現(xiàn)SPMD 線程級(jí)并行。不同于事后數(shù)據(jù)處理每一個(gè)并行線程的數(shù)據(jù)是已知的持久化數(shù)據(jù)，實(shí)時(shí)測控系統(tǒng)并行線程的負(fù)載將對(duì)應(yīng)每一個(gè)UDP Socket接收到的網(wǎng)絡(luò)實(shí)時(shí)測控?cái)?shù)據(jù)。

如圖1所示，并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)框架包含四個(gè)模塊：進(jìn)程初始化模塊、線程初始化模塊、數(shù)據(jù)解析模塊、數(shù)據(jù)持久化模塊。

進(jìn)程初始化模塊負(fù)責(zé)整個(gè)系統(tǒng)的任務(wù)初始化。創(chuàng)建的任務(wù)進(jìn)程P，申請并初始化用于各并行線程間進(jìn)行通信的共享緩沖區(qū)。該共享緩沖區(qū)可以被各個(gè)并行子線程訪問，實(shí)現(xiàn)線程間數(shù)據(jù)通信。同時(shí)讀取任務(wù)配置，根據(jù)配置度量系統(tǒng)的靜態(tài)負(fù)載，并根據(jù)靜態(tài)負(fù)載平衡算法進(jìn)行并行任務(wù)劃分。

線程初始化模塊負(fù)責(zé)初始化使用OpenMP 制導(dǎo)語句Fork 出的各并行子線程?？紤]到存儲(chǔ)系統(tǒng)人機(jī)交互需要，本框架使用Qt 圖形界面專門設(shè)置一個(gè)GUI（Graphical User Interface）線程T0來負(fù)責(zé)處理圖形界面，完成內(nèi)存占用率、多核CPU 的使用率，硬盤使用率等系統(tǒng)資源的監(jiān)視、異常數(shù)據(jù)的顯示、刷新和人機(jī)交互任務(wù)。T1至Tn是數(shù)據(jù)存儲(chǔ)線程，具體個(gè)數(shù)由進(jìn)程初始化模塊中任務(wù)負(fù)載的劃分情況來決定。每個(gè)數(shù)據(jù)存儲(chǔ)線程在Fork 之后第一步會(huì)根據(jù)網(wǎng)絡(luò)配置創(chuàng)建接收數(shù)據(jù)的socket套接字，并創(chuàng)建一個(gè)循環(huán)隊(duì)列緩沖區(qū)用于緩存實(shí)時(shí)數(shù)據(jù)，借助于隊(duì)列先進(jìn)先出的特性保證網(wǎng)絡(luò)接收數(shù)據(jù)的時(shí)序性。

圖1 并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)框架

數(shù)據(jù)解析模塊負(fù)責(zé)UDP數(shù)據(jù)包的解析工作。為了及時(shí)發(fā)現(xiàn)測控?cái)?shù)據(jù)的有效性，存儲(chǔ)系統(tǒng)還需要對(duì)數(shù)據(jù)包做基本的異常性校驗(yàn)工作。各個(gè)數(shù)據(jù)存儲(chǔ)線程響應(yīng)并接收網(wǎng)絡(luò)數(shù)據(jù)后，解析應(yīng)用層協(xié)議包頭并進(jìn)行校驗(yàn)，如果為異常數(shù)據(jù)則首先寫入共享通信緩沖區(qū)，再根據(jù)持久化的要求進(jìn)行持久化。若為正常數(shù)據(jù)則直接根據(jù)持久化需求進(jìn)行持久化操作。GUI線程T0會(huì)根據(jù)線程的同步策略去訪問共享緩沖區(qū)的異常數(shù)據(jù)并在GUI 界面更新，為用戶決策提供依據(jù)。

數(shù)據(jù)持久化模塊負(fù)責(zé)數(shù)據(jù)的持久存儲(chǔ)工作，目前存儲(chǔ)系統(tǒng)大多使用RAID 陣列作為后臺(tái)存儲(chǔ)器。用戶端會(huì)在虛擬磁盤控制器的指導(dǎo)下，根據(jù)控制指令完成數(shù)據(jù)庫文件的讀寫工作。多個(gè)并行線程可以同時(shí)在不同的磁盤上進(jìn)行讀寫，發(fā)揮RAID 陣列并行I/O 的優(yōu)勢。并行I/O 工作主要由RAID 的虛擬磁盤控制器完成，本文不再深入討論。

基于Qt 和OpenMP 的并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)要具備高可擴(kuò)展性和強(qiáng)實(shí)時(shí)性，首先要解決任務(wù)劃分問題。將網(wǎng)絡(luò)數(shù)據(jù)按照流量大小均衡分割為一個(gè)個(gè)并行子域，然后交給各個(gè)存儲(chǔ)線程并行地解析處理，防止單個(gè)線程負(fù)載過重引起的延遲甚至是數(shù)據(jù)丟失。其次是線程間通信的同步問題，本系統(tǒng)的線程間同步任務(wù)主要是T0和某個(gè)存儲(chǔ)線程之間的共享緩存通信同步。某一時(shí)刻點(diǎn)至多關(guān)系到兩個(gè)線程，而OpenMP本身提供的線程同步機(jī)制粒度過大[6]，在處理本系統(tǒng)通信同步時(shí)容易導(dǎo)致全局線程阻塞產(chǎn)生較大延遲，需要設(shè)計(jì)一個(gè)細(xì)粒度的線程間同步算法。最后要利用Qt基于消息和槽機(jī)制的良好人機(jī)交互型特性，還需要將Qt 的特有的事件循環(huán)機(jī)制和OpenMP 線程有效結(jié)合，在OpenMP 線程中實(shí)現(xiàn)事件處理循環(huán)。

3 關(guān)鍵技術(shù)實(shí)現(xiàn)

3.1 靜態(tài)負(fù)載均衡模型

并行程序的性能本身受各線程之間的同步影響較大。如果單個(gè)線程的負(fù)載過重就會(huì)使其運(yùn)行速度下降，導(dǎo)致和其同步線程在同步點(diǎn)長時(shí)間阻塞等待，進(jìn)而使整個(gè)并行程序的運(yùn)行速度大打折扣，降低并行效率。如果單個(gè)線程相比其他線程負(fù)載過輕，該線程就會(huì)過快地完成計(jì)算任務(wù)而在同步點(diǎn)等待，CPU 核長時(shí)間空閑，浪費(fèi)計(jì)算資源?？紤]到動(dòng)態(tài)遷移帶來的額外時(shí)間開銷，本系統(tǒng)采用靜態(tài)負(fù)載均衡思想來解決系統(tǒng)的任務(wù)劃分問題。

根據(jù)系統(tǒng)框架圖所示，抽象的數(shù)據(jù)存儲(chǔ)過程模型如圖2所示。測控設(shè)備將自身處理產(chǎn)生的測控?cái)?shù)據(jù)以UDP數(shù)據(jù)報(bào)的方式發(fā)送進(jìn)入網(wǎng)絡(luò)，存儲(chǔ)系統(tǒng)根據(jù)預(yù)先約定的網(wǎng)絡(luò)地址和端口創(chuàng)建socket并響應(yīng)數(shù)據(jù)接收，將數(shù)據(jù)放入緩沖隊(duì)列，然后繼續(xù)響應(yīng)下一個(gè)網(wǎng)絡(luò)數(shù)據(jù)包。處理模塊從循環(huán)緩沖隊(duì)列取出一包數(shù)據(jù)進(jìn)行校驗(yàn)、存盤等解析工作。如果將測控設(shè)備作為顧客源，存儲(chǔ)系統(tǒng)作為服務(wù)機(jī)構(gòu)，該過程可以用排隊(duì)系統(tǒng)[7-8]來表示。

圖2 數(shù)據(jù)存儲(chǔ)過程的抽象模型

排隊(duì)系統(tǒng)包含三個(gè)要素：輸入過程、排隊(duì)規(guī)則、服務(wù)機(jī)構(gòu)。根據(jù)網(wǎng)絡(luò)設(shè)備基本特點(diǎn)本系統(tǒng)的輸入過程和服務(wù)過程均可以使用負(fù)指數(shù)分布模型來刻畫，由于使用循環(huán)隊(duì)列緩沖區(qū)，有先進(jìn)先出的特性，因此服務(wù)規(guī)則可以對(duì)應(yīng)先來先服務(wù)（First Come First Served，F(xiàn)CFS）原則。這是一個(gè)典型M/M/1模型的排隊(duì)系統(tǒng)[9-10]。

假設(shè)某一個(gè)測控設(shè)備的發(fā)送速率為λ，網(wǎng)絡(luò)的傳送過程沒有數(shù)據(jù)丟包（網(wǎng)絡(luò)可靠性不在本系統(tǒng)考慮范圍），系統(tǒng)的服務(wù)時(shí)間即處理時(shí)間為Ts。本文主要關(guān)心的幾個(gè)參數(shù)包括：

緩沖區(qū)長度Nq，排隊(duì)系統(tǒng)進(jìn)入穩(wěn)態(tài)后，系統(tǒng)內(nèi)長期駐留的數(shù)據(jù)包的個(gè)數(shù)，它確定在保證丟失率為可接收的數(shù)值范圍內(nèi)，應(yīng)為每個(gè)線程分配的緩沖隊(duì)列大??；輸入速率λ，它是線程負(fù)載的直接度量，跟緩沖區(qū)大小有直接關(guān)系，必須確保系統(tǒng)能處理完數(shù)據(jù)，不產(chǎn)生丟失；處理時(shí)間Ts，在保證基本功能的前提下，服務(wù)時(shí)間越短越好。

M/M/1系統(tǒng)在穩(wěn)態(tài)時(shí)平均隊(duì)列的長度滿足式（1）[11]：

其中，ρ為服務(wù)臺(tái)的使用率，是平均到達(dá)率與平均服務(wù)率之比，即在相同時(shí)區(qū)內(nèi)顧客到達(dá)的平均數(shù)與被服務(wù)的平均數(shù)之比，通過網(wǎng)絡(luò)速率λ和服務(wù)速率μ定義，如式（2）：

將式（2）帶回式（1），就得到了本文關(guān)心的三個(gè)要素之間的制約關(guān)系，如式（3）所示：

其中，系統(tǒng)的處理時(shí)間Ts是可以預(yù)知的變量，每個(gè)線程要接收的網(wǎng)絡(luò)數(shù)據(jù)速率λ和緩沖區(qū)隊(duì)列的長度是可變變量。

考慮到計(jì)算核和內(nèi)存的代價(jià)，本系統(tǒng)的靜態(tài)負(fù)載均衡方法的主要步驟如下所示：

（1）預(yù)置一個(gè)緩沖隊(duì)列的大小Nq0由式（3）確定每一個(gè)線程能承受的負(fù)載流量大小λ0。

（2）根據(jù)λ0和總流量M計(jì)算出需要的計(jì)算核個(gè)數(shù)，向上取整。

（3）比較C和服務(wù)器本來可用的CPU 總核數(shù)CN。若C≤CN，則劃分方案可行，開始執(zhí)行任務(wù)；若C＞CN，則計(jì)算核數(shù)不足轉(zhuǎn)到步驟（4）。

（4）在Nq0基礎(chǔ)上增加整數(shù)增量D，即以Nq0+D的大小再次回到步驟（1），繼續(xù)試探直至找到可行的劃分方案為止。

基于排隊(duì)論的靜態(tài)負(fù)載均衡算法可以兼顧計(jì)算核心數(shù)、緩沖隊(duì)列長度和網(wǎng)絡(luò)流量三個(gè)要素的影響，在滿足系統(tǒng)實(shí)時(shí)性、可靠性的前提下尋找到最適合目前服務(wù)器能力的任務(wù)靜態(tài)劃分方案，既能保證并行效率，又能提高資源利用率。

3.2 基于互斥鎖的線程同步算法

在本系統(tǒng)中，存儲(chǔ)線程需要顯示數(shù)據(jù)時(shí)必須先將數(shù)據(jù)寫入對(duì)應(yīng)共享通信緩沖區(qū)，然后由T0即GUI 線程讀取共享數(shù)據(jù)，并在界面更新。在使用單緩沖區(qū)時(shí)，必須要實(shí)現(xiàn)共享緩沖區(qū)的“寫后讀”和“讀后寫”的同步才能保證讀取數(shù)據(jù)的正確性[12]，因此同步算法本身的實(shí)時(shí)性也是系統(tǒng)實(shí)時(shí)性能的瓶頸。OpenMP 本身提供的多線程同步方法為顯示柵欄同步[13]，這將會(huì)強(qiáng)制所有線程在共享緩沖區(qū)讀寫時(shí)同步等待，但本系統(tǒng)中存儲(chǔ)線程之間并不需要協(xié)作，每次同步只有GUI線程和某一個(gè)存儲(chǔ)線程，使用粗粒度的柵欄同步將會(huì)大大地降低系統(tǒng)的實(shí)時(shí)性。本文基于互斥鎖設(shè)計(jì)了細(xì)粒度同步算法來實(shí)現(xiàn)本系統(tǒng)的共享緩沖區(qū)同步任務(wù)。如算法1 所示，以T0和存儲(chǔ)線程Tm的同步為例，其主要步驟包括：

（1）主進(jìn)程P初始化共享緩沖區(qū)和互斥鎖隊(duì)列。根據(jù)存儲(chǔ)線程總數(shù)threads，主進(jìn)程為每一個(gè)存儲(chǔ)線程申請一塊用于共享通信的緩沖區(qū)buffer[i]，其中i為線程編號(hào)，0 ＜i＜threads。同時(shí)為其定義兩把互斥鎖，W[i]用于“寫后讀”同步（下文簡稱寫鎖），保證每個(gè)共享緩沖區(qū)在寫入數(shù)據(jù)后才能被讀取；R[i]用于“讀后寫”同步（下文簡稱讀鎖），保證每個(gè)共享緩沖區(qū)的數(shù)據(jù)被讀取結(jié)束后才能再次擦寫。在任務(wù)開始時(shí)緩沖區(qū)可以用于寫但是不能讀，因此將所有線程的寫鎖初始為開鎖狀態(tài)，而所有讀鎖調(diào)用加鎖操作Lock(W[i])初始化為加鎖狀態(tài)。

（2）存儲(chǔ)線程Tm向共享緩沖區(qū)寫數(shù)據(jù)。線程Tm需要顯示接收的異常數(shù)據(jù)時(shí)，先申請自身對(duì)應(yīng)的共享緩沖區(qū)buffer[m]的“讀后寫”即讀鎖R[m]，若加鎖成功表明該緩沖區(qū)內(nèi)上一次的顯示數(shù)據(jù)已經(jīng)讀取結(jié)束并允許重復(fù)擦寫，那么就將本次的顯示數(shù)據(jù)寫入，并將本共享緩沖區(qū)的“寫后讀”即寫鎖W[m]解鎖，允許GUI線程T0讀取共享緩沖區(qū)的顯示數(shù)據(jù)。否則就進(jìn)入阻塞狀態(tài)，等待T0完成讀取操作釋放緩沖區(qū)的讀鎖。

（3）GUI 線程T0從共享緩沖區(qū)讀取數(shù)據(jù)并更新顯示。由于各個(gè)存儲(chǔ)線程的共享通信緩沖區(qū)相互獨(dú)立，數(shù)據(jù)到達(dá)時(shí)間也相互獨(dú)立。因此本文使用非阻塞加鎖方法[14]Try_Lock（）和循環(huán)輪詢的方式逐個(gè)試探加鎖。若加鎖成功則讀取顯示數(shù)據(jù)，否則就跳過該線程的共享通信過程，對(duì)下一個(gè)線程的共享通信緩沖區(qū)進(jìn)行試探加鎖，如此反復(fù)，直至完成所有存儲(chǔ)線程的共享數(shù)據(jù)顯示任務(wù)。如此，GUI線程就不會(huì)因?yàn)槟骋粋€(gè)線程的共享緩沖區(qū)加鎖不成功而發(fā)生阻塞，影響后續(xù)其他線程的界面更新顯示任務(wù)。其他存儲(chǔ)線程和Tm的同步過程類似，并行運(yùn)行。

算法1OpenMP細(xì)粒度互斥鎖同步算法

Input：線程Tm的顯示數(shù)據(jù)和線程編號(hào)m，總的存儲(chǔ)線程數(shù)threads

//主進(jìn)程P設(shè)置共享緩沖區(qū)，初始化線程鎖

BUFFERbuffer[threads]；

LOCKW[threads]，R[threads]；

Fo（ri=0；i

Lock（W[i]）；

End

//線程Tm

Begin

//向共享緩沖區(qū)m寫入顯示數(shù)據(jù)

Lock（R[m]）

WriteData（buffer[m]）；

Unlock（W[m]）

…

End

西班牙“Maria Canals國際音樂比賽”將于2019年3月23日至4月4日西班牙巴塞羅那舉行。該比賽每年舉行一次，年齡限制：17至28歲。比賽一等獎(jiǎng)獎(jiǎng)金為25，000歐元。比賽共分為四輪，預(yù)選輪：YOUTUBE；第一輪：獨(dú)奏20分鐘；第二輪：獨(dú)奏40分鐘；第三輪：獨(dú)奏50分鐘；決賽輪：協(xié)奏曲。比賽曲目與詳情請關(guān)注網(wǎng)站。

//GUI線程T0

Begin

//從共享緩沖區(qū)讀取存儲(chǔ)線程要顯示數(shù)據(jù)

While（threads）

I（fTry_Lock（W[threads]））

ReadData（buffer[threads]）；

threads??；

Unlock（R[threads]）

End if

End while

End

Output：在圖形界面顯示Tm收到的異常數(shù)據(jù)

該算法能保證每次共享緩存通信過程中最多鎖住T0和另一個(gè)存儲(chǔ)線程，即使這兩個(gè)線程間運(yùn)行速度差異較大造成加鎖阻塞，也不會(huì)引起其他線程的同步空等，保證了其他存儲(chǔ)線程能正常地處理實(shí)時(shí)網(wǎng)絡(luò)數(shù)據(jù)而不丟包，提高并行存儲(chǔ)系統(tǒng)的可靠性和實(shí)時(shí)性。

3.3 在OpenMP線程內(nèi)嵌入事件循環(huán)

本系統(tǒng)使用單獨(dú)的GUI 線程來處理界面顯示和刷新任務(wù)本身可以有效地緩解圖形界面處理帶來的資源消耗壓力，但圖形界面的主要目的是實(shí)現(xiàn)良好的人機(jī)交互，響應(yīng)用戶操作來控制其他存儲(chǔ)線程記錄的開始、停止等工作?；赒t組件的圖形界面使用特有的信號(hào)與槽通信機(jī)制來完成事件處理工作[15]，而OpenMP線程本身并不支持事件處理工作。

OpenMP各個(gè)并行線程復(fù)制運(yùn)行同一份程序代碼，變量名稱完全一致，但都是thread loacal局部變量，互相隔離不能訪問。那么GUI 線程就不能直接和其他存儲(chǔ)線程實(shí)現(xiàn)信號(hào)和槽的跨線程連接。本文通過在主進(jìn)程中設(shè)置橋接對(duì)象的方式實(shí)現(xiàn)OpenMP 各線程隔離對(duì)象之間信號(hào)和槽的跨線程連接。

如圖3所示，T0線程的私有對(duì)象Object_1發(fā)送的控制信號(hào)Signal_1 首先和主進(jìn)程P中可訪問的共享對(duì)象Bridge 的槽函數(shù)Slot 相連接。信號(hào)觸發(fā)時(shí)，Slot 槽函數(shù)會(huì)使用Qt的emit函數(shù)發(fā)送自身定義的傳導(dǎo)信號(hào)Signal，而Signal信號(hào)事先和存儲(chǔ)線程Tm的私有對(duì)象Object_2的槽函數(shù)Slot_2 相連接。傳導(dǎo)信號(hào)Signal 被時(shí)間觸發(fā)后就會(huì)加入線程Tm的消息隊(duì)列，激活線程Tm的槽函數(shù)Slot_2 進(jìn)行響應(yīng)，并完成圖形界面要求的相關(guān)操作。如圖中虛線所示，間接地實(shí)現(xiàn)了OpenMP線程間私有對(duì)象之間信號(hào)和槽的鏈接。

圖3 信號(hào)和槽跨OpenMP線程橋接

當(dāng)消息進(jìn)入并行子線程的消息隊(duì)列之后，仍需要事件循環(huán)機(jī)制來保證消息的正常處理過程。OpenMP 線程本身并不具備處理Qt消息隊(duì)列的功能。借助于Qt本身的事件循環(huán)機(jī)制，整個(gè)OpenMP線程的事件處理流程如算法2所示。

算法2OpenMP線程事件處理機(jī)制

Input：QEvent事件隊(duì)列

//section1

#pragma omp parallel num_threads（thread_count）

{

QEventLoopeventLoop；

//處理本線程網(wǎng)絡(luò)數(shù)據(jù)

//Do something

//委任eventLoop處理事件循環(huán)->見section 2

eventLoop.exec（）；

}

//section2

int QEventLoop::exec（ProcessEventsFlagsflags）

{

//獲取私有數(shù)據(jù)指針d

Q_D（QEventLoop）；

…

//事件循環(huán)，消息隊(duì)列空則退出循環(huán)

while（!d->exit.loadAcquire（））

{

//處理事件

processEvents（flags|WaitForMoreEvents|EventLoopExec）；

}

//阻塞等待

wait_for_more_events();

Output：QEvent的操作結(jié)果

如section1 部分偽代碼所示，每個(gè)OpenMP 線程在Fork 之后創(chuàng)建一個(gè) QEventLoop 事件循環(huán)對(duì)象[16]，然后才開始創(chuàng)建Socket并處理網(wǎng)絡(luò)數(shù)據(jù)，在每個(gè)線程的末尾調(diào)用QEventLoop 的成員函數(shù)exec（），委托QEventLoop處理事件循環(huán)。事件循環(huán)的輪廓如section2 所示，事件首先進(jìn)入線程的私有事件隊(duì)列d中。事件處理過程會(huì)循環(huán)遍歷事件隊(duì)列，并且將入棧的事件發(fā)送到它們的目標(biāo)對(duì)象當(dāng)中，如果隊(duì)列為空就會(huì)阻塞等待新的事件到來，如此循環(huán)實(shí)現(xiàn)整個(gè)線程的事件循環(huán)。

通過橋接和事件循環(huán)機(jī)制，本文將Qt 的事件循環(huán)機(jī)制嵌入OpenMP 線程，在保持OpenMP 線程級(jí)并行優(yōu)勢的同時(shí)還兼顧了Qt以消息驅(qū)動(dòng)的圖形界面良好的人機(jī)交互性能。

4 實(shí)驗(yàn)與分析

為了測試系統(tǒng)的性能，本文在4*28核Intel Core i7處理器，64 GB DDR3內(nèi)存，配備10 Gb/s萬兆網(wǎng)，RAID5磁盤陣列的服務(wù)器硬件環(huán)境下進(jìn)行了測試。

首先是系統(tǒng)的可擴(kuò)展性測試。并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)關(guān)注的可擴(kuò)展性主要指系統(tǒng)在網(wǎng)絡(luò)流量不斷變化的情況下，能否充分利用計(jì)算資源來確保系統(tǒng)的實(shí)時(shí)性，即響應(yīng)時(shí)間維持在較低水平而不是隨流量的變化發(fā)生較大變化。當(dāng)系統(tǒng)測試環(huán)境確定后，數(shù)據(jù)包從解析到寫入數(shù)據(jù)庫的時(shí)間即系統(tǒng)服務(wù)時(shí)間就已經(jīng)被確定。系統(tǒng)的響應(yīng)時(shí)間主要取決于數(shù)據(jù)在緩沖隊(duì)列中的等待時(shí)間，等待時(shí)間越短實(shí)時(shí)性就越高。本文在保證全部輸入數(shù)據(jù)都是正常數(shù)據(jù)的前提下，測試了單線程存儲(chǔ)系統(tǒng)和并行多線程存儲(chǔ)系統(tǒng)的響應(yīng)時(shí)間隨系統(tǒng)輸入總流量的變化情況。測試結(jié)果如圖4所示，其中多線程的系統(tǒng)響應(yīng)時(shí)間采用每個(gè)存儲(chǔ)線程響應(yīng)時(shí)間的統(tǒng)計(jì)平均值。

從實(shí)驗(yàn)結(jié)果可以看出，在系統(tǒng)流量為0 時(shí)，單線程和多線程系統(tǒng)與縱軸的交點(diǎn)即為系統(tǒng)的服務(wù)時(shí)間，本文的測試環(huán)境下系統(tǒng)的服務(wù)時(shí)間為20 ms，二者一致。隨著總流量的不斷增加，由于單線程系統(tǒng)只有一個(gè)讀寫線程，因此數(shù)據(jù)將會(huì)在緩沖區(qū)中累積，流量越大累積越多，排隊(duì)時(shí)間越長，平均響應(yīng)時(shí)間也越來越長，甚至出現(xiàn)丟包影響系統(tǒng)的實(shí)時(shí)性。并行系統(tǒng)在靜態(tài)負(fù)載均衡算法的幫助下會(huì)進(jìn)行任務(wù)劃分，確定使用的計(jì)算核心數(shù)，基本保證了每個(gè)線程的流量負(fù)載都維持較低水平，而且大致相同，因此平均響應(yīng)時(shí)間并不會(huì)隨著系統(tǒng)總流量的增加而增加，而是基本保持在單核低負(fù)載時(shí)的水平。

圖4 響應(yīng)時(shí)間隨系統(tǒng)總流量的變化情況

實(shí)時(shí)系統(tǒng)另一個(gè)重要指標(biāo)就是系統(tǒng)的容錯(cuò)性。并行實(shí)時(shí)測控存儲(chǔ)系統(tǒng)關(guān)注的容錯(cuò)性主要指在異常數(shù)據(jù)的干擾下系統(tǒng)能否做出正確的處理而不影響系統(tǒng)的響應(yīng)時(shí)間，導(dǎo)致系統(tǒng)丟包。在保證總流量保持在80 MB/s較高負(fù)載的情況下，通過不斷增加異常數(shù)據(jù)的比例，來統(tǒng)計(jì)系統(tǒng)的響應(yīng)時(shí)間，測試系統(tǒng)的容錯(cuò)性，測試結(jié)果如圖5所示。

圖5 系統(tǒng)響應(yīng)時(shí)間隨異常數(shù)據(jù)比例的變化情況

從測試結(jié)果可以看出，在異常數(shù)據(jù)的比例較低時(shí)，對(duì)系統(tǒng)的響應(yīng)時(shí)間影響較小。當(dāng)增大到40%以上時(shí)，系統(tǒng)的響應(yīng)時(shí)間明顯出現(xiàn)延遲。這主要是因?yàn)楫惓?shù)據(jù)在寫入數(shù)據(jù)庫之前，需要在圖形界面顯示給用戶，而顯示過程要和GUI 線程進(jìn)行同步通信。盡管本文設(shè)計(jì)了細(xì)粒度同步方法，但GUI線程要負(fù)責(zé)所有其他存儲(chǔ)線程的異常數(shù)據(jù)顯示任務(wù)，負(fù)載過重，就會(huì)引起個(gè)別存儲(chǔ)線程的等待阻塞，導(dǎo)致平均響應(yīng)時(shí)間發(fā)生突變。

綜上實(shí)驗(yàn)表明，并行實(shí)時(shí)測控存儲(chǔ)系統(tǒng)在系統(tǒng)流量較大，負(fù)載較高的情況下，相比現(xiàn)行的串行存儲(chǔ)系統(tǒng)具有更好的可擴(kuò)展性、更強(qiáng)的實(shí)時(shí)性，能更好地發(fā)揮系統(tǒng)的硬件資源優(yōu)勢，進(jìn)一步提高系統(tǒng)的綜合性能。

5 總結(jié)

本文通過引入M/M/1模型的排隊(duì)系統(tǒng)，設(shè)計(jì)了一種適合并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)的靜態(tài)任務(wù)劃分算法。基于互斥鎖完成了線程間的細(xì)粒度通信同步機(jī)制。借助于事件循環(huán)機(jī)制將Qt的信號(hào)與槽特性成功地嵌入OpenMP線程，保留了二者的優(yōu)點(diǎn)。在此基礎(chǔ)上設(shè)計(jì)并實(shí)現(xiàn)了一套并行實(shí)時(shí)測控?cái)?shù)據(jù)存儲(chǔ)系統(tǒng)框架，并進(jìn)行了測試。實(shí)驗(yàn)表明，該系統(tǒng)對(duì)現(xiàn)行的測控?cái)?shù)據(jù)存儲(chǔ)任務(wù)而言具有更好的擴(kuò)展性、實(shí)時(shí)性和一定容錯(cuò)能力。后續(xù)，本文將針對(duì)系統(tǒng)容錯(cuò)能力閾值不高的問題，采用異常數(shù)據(jù)挑點(diǎn)顯示、設(shè)置顯示緩沖區(qū)等多種方法來減輕GUI線程的負(fù)載，進(jìn)一步提高系統(tǒng)的可靠性。