專利名稱：一種消息的讀寫方法和裝置的制作方法
技術領域：
本發(fā)明涉及計算機技術領域，特別是涉及 一種消息的讀寫方法和 裝置。
背景技術：
通過消息隊列進行數(shù)據(jù)傳輸是UNIX操作系統(tǒng)的IPC (Inter Process Communication,進程間通訊)的基本方法之一，被廣泛地使 用于分布式應用程序間的數(shù)據(jù)交換。應用程序通過調用系統(tǒng)提供的 API ( Application Programming Interface,應用程序接口 )函數(shù)訪問目
標消息隊列，讀取或寫入數(shù)據(jù)。根據(jù)調用函數(shù)的不同，應用程序可以 分為兩種，消息的生產(chǎn)者和消費者，消息的生產(chǎn)者和消費者通過指定 所發(fā)或所收消息的類型來建立聯(lián)系。每一條消息在消息隊列中都是唯 一的，只能被一個生產(chǎn)者發(fā)送后進入隊列，被一個消費者接收后取出 隊列。
任何一個消息隊列都支持多個應用進程或線程同時對其訪問，消 息隊列系統(tǒng)提供互斥處理機制，可以保證各個應用進程或線程的安全 訪問，不會出現(xiàn)沖突。其中，多個應用進程或線程可以處理不同類型 的消息。例如，A進程發(fā)送X類型的消息，B進程發(fā)送Y類型的消 息，C進程接收X類型的消息，D進程接收Y類型的消息，因此進 程A、 C和B、 D分別配對，而彼此間沒有影響。另外，多個應用進 程或線程也可以處理相同類型的消息。例如，A進程發(fā)送X類型的 消息，B、 C、 D進程都接收X類型的消息，當有一條X類型的消息 到達隊列時，B、 C、 D其中的一個可以收到這條消息，其他進程則 處于等待狀態(tài)。
消息隊列支持兩種使用模式， 一種使用模式為首先，消息的生產(chǎn)者產(chǎn)生某種類型的消息，并將該消息放入消息隊列；然后，消息的 消費者從消息隊列中接收該類型的消息。如果有多個消息的消費者， 則消費者按照調用的先后順序從隊列中接收消息，直到隊列中該類型
的消息為空。另一種使用模式為如果消息隊列中某種類型的消息為 空，則消息的消費者調用接收函數(shù)，處于等待狀態(tài)；當消息的生產(chǎn)者 產(chǎn)生該類型的消息并將該消息放入消息隊列時，消息的消費者就可以 立即取得該消息。
在實現(xiàn)本發(fā)明過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術中至少存在如下問 題當消息隊列中的某一類型的消息為空，且同時有大量消息的消費 者處于等待狀態(tài)時，該些消費者不占用CPU時間；而當消息的生產(chǎn) 者產(chǎn)生某種類型的消息并將該消息放入消息隊列時，所有處于等待狀 態(tài)的消費者都被喚醒，而無論該消費者是否需要接收該種類型的消 息。被喚醒的消費者會在消息隊列中對需要的消息進行査詢，其中一 個消費者收到該消息，而其他消費者會在遍歷所有的消息后再次進入 等待狀態(tài)。因此，當消息的產(chǎn)生非常頻繁時，所有處于等待狀態(tài)的消 費者會被反復喚醒，因此該些消費者會占用大量的CPU時間，產(chǎn)生 非常大的無謂的系統(tǒng)開銷，消息的并發(fā)接收能力急劇下降。當硬件系 統(tǒng)采用多CPU結構時，產(chǎn)生的問題更加明顯。

發(fā)明內(nèi)容
本發(fā)明實施例要解決的問題是提供 一 種消息的讀寫方法和裝置， 以克服現(xiàn)有技術中由于消費者被無謂喚醒而造成占用大量CPU時間
的缺陷。
為達到上述目的，本發(fā)明實施例的技術方案提供 一種消息的讀寫
方法，包括以下步驟將消息從生產(chǎn)者發(fā)送到消息隊列的步驟；根據(jù)
所述消息的類型，查詢消息同步表，如果所述消息同步表中存在與所
述消息的類型對應的記錄，則確認有對應的消費者的步驟；當有對應 的消費者時，喚醒所述對應的消費者中的一個消費者的步驟；將所述
6消息發(fā)送給所述被喚醒的消費者的步驟。
其中，在所述生產(chǎn)者喚醒對應的消費者中的一個消費者的步驟 中，具體包括獲取與所述消息的類型對應的記錄的下標；如果所述 記錄的等待消費者的數(shù)量大于O，則獲取與所述下標對應的消息同步 信號燈，對所述消息同步信號燈進行V操作，并將所述記錄中等待 消費者的數(shù)量減1。
其中，在所述生產(chǎn)者查詢消息同步表之前，還包括消費者加入等
待隊列的步驟，該消費者加入等待隊列的步驟具體包括根據(jù)需讀取
消息的類型，查詢所述消息同步表，如果所述消息同步表中存在與所 述需讀取消息的類型對應的記錄，則將所述記錄中等待消費者的數(shù)量
加i;獲取與所述需讀取消息的類型對應的記錄的下標；獲取與所述 下標對應的消息同步信號燈；對所述消息同步信號燈進行P操作。
其中，在所述生產(chǎn)者查詢消息同步表之前，還包括消費者建立消 息同步表記錄并加入等待隊列的步驟，該消費者建立消息同步表記錄 并加入等待隊列的步驟具體包括根據(jù)需讀取消息的類型，查詢所述 消息同步表，如果所述消息同步表中沒有與所述需讀取消息的類型對 應的記錄，則在所述消息同步表中建立消息同步表記錄，并對所述記
錄進行初始化；獲取所述記錄的下標；獲取與所述下標對應的消息同 步信號燈；對所述消息同步信號燈進行P操作。
其中，所述對記錄進行初始化具體包括將所述記錄的消息類型 設置為所述需讀取消息的類型；將所述記錄的等待消費者的數(shù)量設置 為l。
其中，在所述被喚醒的消費者讀取消息之前，還包括如下步驟 判斷所述等待消費者的數(shù)量是否為0，如果是，則清除所述記錄。 其中，在所述生產(chǎn)者查詢消息同步表之前，還包括如下步驟建
立消息同步信號燈集；建立消息同步表，所述消息同步表中表項的數(shù) 量與所述消息同步信號燈集中的消息同步信號燈的數(shù)量相同；對所述消息同步表進行初始化。
其中，所述對消息同步表進行初始化具體包括將所述消息同步 表的消息類型設置為-1;將所述消息同步表的記錄的數(shù)量設置為0。
本發(fā)明實施例的技術方案還提供了一種消息的讀寫裝置，包括
發(fā)送裝置，用于將消息從生產(chǎn)者發(fā)送到消息隊列；查詢裝置，用于根
據(jù)所述消息的類型，查詢消息同步表，如果所述消息同步表中存在與
所述消息的類型對應的記錄，則確認有對應的消費者；喚醒裝置，當 有對應的消費者時，喚醒所述對應的消費者中的一個消費者；將所述 消息發(fā)送給所述被喚醒的消費者的裝置。
其中，所述消息的讀寫裝置還包括信號燈集建立單元，用于建 立消息同步信號燈集；消息同步表建立單元，用于建立消息同步表， 所述消息同步表中表項的數(shù)量與所述消息同步信號燈集中的消息同 步信號燈的數(shù)量相同；消息同步表初始化單元，用于對所述消息同步 表進行初始化。
上述技術方案僅是本發(fā)明的一個優(yōu)選技術方案，具有如下優(yōu)點 本發(fā)明實施例通過生產(chǎn)者根據(jù)消息的類型，在消息同步表中查詢有對 應的消費者，并喚醒其中的一個消費者的方法，使得消費者不會被無 謂喚醒，從而節(jié)省了 CPU時間。


圖l是本發(fā)明實施例的 一種消息同步表的結構圖； 圖2是本發(fā)明實施例的 一種消息的讀寫方法的流程圖。
具體實施例方式
下面結合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細 描述。以下實施例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。
本發(fā)明釆用基于內(nèi)存的BQS (Buffer Queue System,消息隊列系 統(tǒng))，該BQS釆用鏈表式數(shù)據(jù)結構，利用UNIX系統(tǒng)的IPC進程間通訊 (共享內(nèi)存、信號燈)技術，使得消息的生產(chǎn)者和消息的消費者可以
8對消息隊列進行操作，完成應用進程或線程間的數(shù)據(jù)交換。
一個BQS中可以包含多個消息隊列，各個消息隊列之間相互獨 立。每個消息隊列中可以包含多種類型的消息，每種類型的消息鏈表
中可以包含多個消息或空消息。在BQS中，每個消息可以釆用分段存
儲方式存儲在多個數(shù)據(jù)段中，每個數(shù)據(jù)段存儲區(qū)的大小可以根據(jù)消息 的長度而定，既可以節(jié)省存儲區(qū)空間，又可以提高消息操作的靈活性。
本發(fā)明實施例在釆用BQS時，需要完成以下操作過程首先，建 立消息同步信號燈集，所述消息同步信號燈集用于消息同步，其數(shù)量 可以根據(jù)BQS能夠支撐的最大并發(fā)數(shù)而定；然后，建立消息同步表， 所述消息同步表中表項的數(shù)量與所述消息同步信號燈集中的消息同 步信號燈的數(shù)量相同；最后，對所述消息同步表進行初始化，其初始 化過程具體為將所述消息同步表的消息類型設置為-1，即設置 mtype--l;將所述消息同步表的記錄的數(shù)量設置為O,即設置count二0。
本發(fā)明實施例的 一種消息同步表的結構如圖1所示，該消息同步 表包括n個表項，所述表項的下標Idx分別為0， 1, 2……，n-l;每 個表項對應一個消息同步信號燈，用于記錄消息類型和需讀取所述類 型的消息的等待消費者的數(shù)量。所述表項中存儲的記錄可以由生產(chǎn)者
和消費者進行互斥地查詢和修改。
釆用B Q S時，本發(fā)明實施例的 一 種消息的讀寫方法如圖2所示，
首先將消息從生產(chǎn)者發(fā)送到消息隊列，然后根據(jù)所述消息的類型，查 詢是否有對應的消費者，如果有，則喚醒所述對應的消費者中的一個 消費者，最后被喚醒的消費者讀取所述消息。參照圖2，本實施例包 括以下步驟
步驟s201，消費者加入等待隊列。其加入過程包括以下步驟 步驟s2011,根據(jù)需讀取消息的類型，查詢消息同步表，如果所 述消息同步表中沒有與所述需讀取消息的類型對應的記錄，則轉步驟 s2012;否則轉步驟s2013。本實施例中假設該消費者需讀取type類型的消息，則調用MsgQueSynTbl—Alloc(type)對消息同步表進行查詢。步驟s2012，在所述消息同步表中建立消息同步表記錄，并對所述記錄進行初始化，然后轉步驟s2014。所述對記錄進行初始化具體包括將所述記錄的消息類型設置為所述需讀取消息的類型，即設置mtype=type;將所述記錄的等待消費者的數(shù)量設置為1，即設置count=l。
步驟s2013,將所述記錄中等待消費者的數(shù)量加1，即執(zhí)行count++。
步驟s2014,獲取所述記錄的下標MsgQueSynTblIndex。
步驟s2015，對BQS核心資源進行信號燈V操作，使得其他應用進程或線程能夠訪問BQS。所述BQS核心資源由消息的實體數(shù)據(jù)區(qū)、鏈式索引數(shù)據(jù)區(qū)及消息同步表共同構成。所述V操作是不可中斷的程序段，稱為V原語。V原語操作的動作為首先信號量sem加l;然后若信號量sem加l后大于零，則進程繼續(xù)執(zhí)行；若信號量sem加1后小于或等于零，則從該信號的等待隊列中喚醒一等待進程，然后再返回原進程繼續(xù)執(zhí)行或轉進程調度。
步驟s2016，根據(jù)所述記錄的下標MsgQueSynTblIndex，獲取與
所述下標對應的消息同步信號燈。
步驟s2017，對所述消息同步信號燈進行P操作，即調用T—Mutex—SemP ( MsgQueSynTblIndex),等待消息到達的信號喚醒。所述P操作是不可中斷的程序段，稱為P原語。P原語操作的動作為首先信號量sem減l;然后若信號量sem減1后仍大于或等于零，則進程繼續(xù)執(zhí)行；若sem減l后小于零，則該進程被阻塞后進入與該信號相對應的隊列中，轉進程調度。
步驟s202,將消息從生產(chǎn)者發(fā)送到消息隊列。首先對BQS核心資源進行信號燈P操作，使得所有使用BQS的應用進程或線程達到同步；然后，將消息類型為type的消息從該生產(chǎn)者發(fā)送到指定的消
10息隊列中。
步驟S203,根據(jù)消息的類型，查詢是否有對應的消費者。如果有，
則轉步驟s204,否則對BQS核心資源進行信號燈V操作，返回O并結東。其查詢過程為根據(jù)所述消息的類型type ，調用GetMsgQueSynldxByMType (type)，查詢消息同步表，如果所述消息同步表中存在與type類型的記錄，則確認有對應的消費者；否則沒有對應的消費者。
步驟s204，喚醒所述對應的消費者中的一個消費者。其喚醒過程具體包括首先，獲取與所述消息的類型type對應的記錄的下標MsgQueSynTblIndex;然后，如果所述記錄的等待消費者的數(shù)量大于0，則根據(jù)所述記錄的下標MsgQueSynTblIndex,獲取與所述下標對應的消息同步信號燈；調用T—Mutex_SemV(MsgQueSynTblIndex),對所述消息同步信號燈進行V操作，喚醒等待接收type類型消息的消費者，并將所述記錄中等待消費者的數(shù)量減1。再對BQS核心資源進行信號燈V操作，使得其他應用進程或線程能夠訪問BQS，消息寫入成功后返回0。如果有多個消費者等待接收type類型的消息，當寫入消息后，進行同步表信號燈V操作，此時只有一個消費者被喚醒，其他消費者仍然處于信號燈睡眠狀態(tài)，不會因為一個消息的到達，造成各個消費者對系統(tǒng)CPU資源的占用。而對被喚醒消費者的選擇，則根據(jù)操作系統(tǒng)的信號燈實現(xiàn)而定，且對多個接收type類型消息的消費者來說，各個消費者能夠取得該消息的機會是均等的。
步驟s205,對消息同步記錄進行清理。首先，對BQS核心資源進行信號燈P操作，使得所有使用BQS的應用進程或線程達到同步的效果；然后，判斷所述等待消費者的數(shù)量是否為O,如果是，則清除所述記錄；最后，對BQS核心資源進行信號燈V操作，使得其他應用進程或線程能夠訪問BQS。
步驟s206,將所述消息發(fā)送給所述被喚醒的消費者。其發(fā)送過程
ii包括以下步驟
步驟s2061,根據(jù)消息類型type，在消息隊列中進行查詢，如果查詢到所述消息隊列中有類型為type的消息，則轉步驟s2062;否則轉步驟s2064。
步驟s2062，將所述消息從所述消息隊列發(fā)送到所述被喚醒的消費者。
步驟s2063，對BQS核心資源進行信號燈V操作，使得其他應用進程或線程能夠訪問BQS，返回消息體的長度并結東。
步驟s2064，判斷讀取消息的標志是否為NO—WAIT，如果是，則返回-1并結東；否則進行加入等待隊列的操作。
在進行步驟s206時，如果在此段時間內(nèi)，沒有將消息類型為type的消息發(fā)送給其他消費者，則該消息類型為type的消息一定能夠發(fā)送到該消費者；如果消息類型為type的消息被發(fā)送到該消費者前，全部被發(fā)送到其他消費者，則仍然沒有消息類型為type的消息被發(fā)送到該消費者，該消費者處于饑餓狀態(tài)，繼續(xù)進行加入等待隊列的操作。
當多個消費者等待同一種類型的消息時，例如消費者l、消費者2和消費者n都在等待類型為mtype—1的消息，該消息類型mtype—1在消息同步表中分配到idpO表項；如果有三個生產(chǎn)者將產(chǎn)生的消息發(fā)送到消息隊列，其中生產(chǎn)者1和生產(chǎn)者2都發(fā)送了類型為mtype_ 1的消息，生產(chǎn)者n發(fā)送了類型為mtype_2的消息。本發(fā)明實施例的 一 種消息的讀寫流程包括以下步驟
步驟s301，消費者l等待消息時，以消息類型mtype一l從消息同步表中分配到idxi表項，也就擁有了BQS消息信號燈的第idx^項的使用權，并進行T—Mutex—SemP操作。
步驟s302，消費者2等待消息時，以消息類型mtype—l從消息同步表中檢索到idFO表項，同樣擁有了 BQS消息信號燈的第idFO項的使用權，并進行T一Mutex—SemP操作。
12步驟s303，消費者n等待消息時，以消息類型mtype一l從消息同步表中檢索到icb^0表項，同樣擁有了 BQS消息信號燈的第idx:0項的使用權，并進行T—Mutex—SemP操作。
步驟s304，生產(chǎn)者l將消息寫入消息隊列后，檢索到類型mtype—1已經(jīng)有消費者等待接收，也就擁有了 B Q S消息信號燈的第idx=0項的使用權，并進行T—Mutex—SemV操作。此時，消費者l、消費者2和消費者n中的一個消費者被喚醒，取得消息。
步驟s305,生產(chǎn)者2將消息寫入消息隊列后，檢索到類型mtype—1已經(jīng)有消費者等待接收，也就擁有了BQS消息信號燈的第icb^O項的使用權，并進行T一Mutex一SemV操作。此時，剩余的消費者中的一個
消費者被喚醒，取得消息。
步驟s306，生產(chǎn)者n將消息寫入消息隊列后，檢索到類型mtype—2
未有消費者等待接收，操作結東。
經(jīng)過上述過程后，消費者中的最后 一個仍然處于接收等待狀態(tài)；消息隊列中有 一 條類型為mtype_2的消息。
當多個消費者等待不同類型的消息時，例如消費者l等待類型為mtype—l的消息，消費者2等待類型為mtype—2的消息，消費者n等待類型為mtype—n的消息，該消息類型mtype—1在消息同步表中分配到idx二0表項，該消息類型mtype一2在消息同步表中分配至ijidx^表項，該消息類型mtype一n在消息同步表中分配到idx-2表項；如果有三個生產(chǎn)者將產(chǎn)生的消息發(fā)送到消息隊列，其中生產(chǎn)者l發(fā)送了類型為mtype一l的消息，生產(chǎn)者2發(fā)送了類型為mtype—2的消息，生產(chǎn)者n發(fā)送了類型為mtyp^n的消息。本發(fā)明實施例的 一種消息的讀寫流程包括以下步驟
步驟s401，消費者l等待消息時，以消息類型mtype一l從消息同步表中分配到icb^O表項，也就擁有了 BQS消息信號燈的第idFO項的使步驟s402，消費者2等待消息時，以消息類型mtype—2從消息同步 表中分配到i(b^l表項，也就擁有了 BQS消息信號燈的第idx^項的使 用權，并進行T一Mutex—SemP操作。
步驟s403，消費者n等待消息時，以消息類型mtype—n從消息同步 表中分配到idx-2表項，也就擁有了 BQS消息信號燈的第icb^2項的使 用權，并進行T—Mutex—SemP操作。
步驟s404，生產(chǎn)者l將消息寫入消息隊列后，檢索到類型mtype—1 已經(jīng)有消費者等待接收，也就擁有了BQS消息信號燈的第idx-O項的 使用權，并進行T一Mutex—SemV操作。此時，消費者l被喚醒，取得 消息。
步驟s405，生產(chǎn)者2將消息寫入消息隊列后，檢索到類型mtype—2 已經(jīng)有消費者等待接收，也就擁有了 BQS消息信號燈的第idx^項的 使用權，并進行T一Mutex一SemV搡作。此時，消費者2被喚醒，取得 消息。
步驟s406，生產(chǎn)者n將消息寫入消息隊列后，檢索到類型mtype一n 已經(jīng)有消費者等待接收，也就擁有了 B Q S消息信號燈的第i dx=2項的 使用權，并進行T—Mutex一SemV搡作。此時，消費者n被喚醒，取得 消息。
經(jīng)過上述過程后，所有的消費者都已經(jīng)取得消息，消息隊列中無 任何消息。
本發(fā)明實施例通過生產(chǎn)者根據(jù)消息的類型，在消息同步表中查詢 有對應的消費者，并喚醒其中的一個消費者的方法，使得消費者不會 被無謂喚醒，從而節(jié)省了CPU時間。
本發(fā)明實施例的一種消息的讀寫裝置，包括發(fā)送裝置，用于將 消息從生產(chǎn)者發(fā)送到消息隊列；查詢裝置，用于根據(jù)所述消息的類型, 查詢消息同步表，如果所述消息同步表中存在與所述消息的類型對應 的記錄，則確認有對應的消費者；喚醒裝置，當有對應的消費者時，
14喚醒所述對應的消費者中的 一個消費者；將所述消息發(fā)送給所述被喚
醒的消費者的裝置；信號燈集建立單元，用于建立消息同步信號燈集; 消息同步表建立單元，用于建立消息同步表，所述消息同步表中表項 的數(shù)量與所述消息同步信號燈集中的消息同步信號燈的數(shù)量相同；消 息同步表初始化單元，用于對所述消息同步表進行初始化。
通過以上的實施方式的描述，本領域的技術人員可以清楚地了解 到本發(fā)明可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，因此，本 發(fā)明的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟 件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質中， 包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器, 或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例所述的方法。
以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領 域的普通技術人員來說，在不脫離本發(fā)明技術原理的前提下，還可以 做出若干改進和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。
權利要求
1、一種消息的讀寫方法，其特征在于，包括以下步驟將消息從生產(chǎn)者發(fā)送到消息隊列的步驟；根據(jù)所述消息的類型，查詢消息同步表，如果所述消息同步表中存在與所述消息的類型對應的記錄，則確認有對應的消費者的步驟；當有對應的消費者時，喚醒所述對應的消費者中的一個消費者的步驟；將所述消息發(fā)送給所述被喚醒的消費者的步驟。
2、 如權利要求1所述消息的讀寫方法，其特征在于，在所述喚 醒對應的消費者中的一個消費者的步驟中，具體包括獲取與所述消息的類型對應的記錄的下標；如果所述記錄的等待消費者的數(shù)量大于O，則獲取與所述下標對 應的消息同步信號燈，對所述消息同步信號燈進行V操作，并將所 述記錄中等待消費者的數(shù)量減1。
3、 如權利要求1所述消息的讀寫方法，其特征在于，在所述查 詢消息同步表之前，還包括消費者加入等待隊列的步驟，該消費者加 入等待隊列的步驟具體包括根據(jù)需讀取消息的類型，查詢所述消息同步表，如果所述消息同 步表中存在與所述需讀取消息的類型對應的記錄，則將所述記錄中等 待消費者的數(shù)量加i;獲取與所述需讀取消息的類型對應的記錄的下標；獲取與所述下標對應的消息同步信號燈；對所述消息同步信號燈進行P操作。
4、 如權利要求l所述消息的讀寫方法，其特征在于，在所述查 詢消息同步表之前，還包括消費者建立消息同步表記錄并加入等待隊 列的步驟，該消費者建立消息同步表記錄并加入等待隊列的步驟具體 包括根據(jù)需讀取消息的類型，查詢所述消息同步表，如果所述消息同 步表中沒有與所述需讀取消息的類型對應的記錄，則在所述消息同步 表中建立消息同步表記錄，并對所述記錄進行初始化；獲取所述記錄的下標；獲取與所述下標對應的消息同步信號燈；對所述消息同步信號燈進行p操作。
5、 如權利要求4所述消息的讀寫方法，其特征在于，所述對記錄進行初始化具體包括將所述記錄的消息類型設置為所述需讀取消息的類型；將所述記錄的等待消費者的數(shù)量設置為1。
6、 如權利要求1所述消息的讀寫方法，其特征在于，在所述被 喚醒的消費者讀取消息之前，還包括如下步驟判斷所述等待消費者的數(shù)量是否為0，如果是，則清除所述記錄。
7、 如權利要求1至6任一項所述消息的讀寫方法，其特征在于， 在所述生產(chǎn)者查詢消息同步表之前，還包括如下步驟建立消息同步信號燈集；建立消息同步表，所述消息同步表中表項的數(shù)量與所述消息同步 信號燈集中的消息同步信號燈的數(shù)量相同；對所述消息同步表進行初始化。
8、 如權利要求7所述消息的讀寫方法，其特征在于，所述對消 息同步表進行初始化具體包括將所述消息同步表的消息類型設置為-1; 將所述消息同步表的記錄的數(shù)量設置為o。
9、 一種消息的讀寫裝置，其特征在于，包括 發(fā)送裝置，用于將消息從生產(chǎn)者發(fā)送到消息隊列；查詢裝置，用于根據(jù)所述消息的類型，查詢消息同步表，如果所 述消息同步表中存在與所述消息的類型對應的記錄，則確認有對應的消費者；喚醒裝置，當有對應的消費者時，喚醒所述對應的消費者中的一 個消費者；將所述消息發(fā)送給所述被喚醒的消費者的裝置。
10、如權利要求9所述消息的讀寫裝置，其特征在于，所述消息 的讀寫裝置還包括信號燈集建立單元，用于建立消息同步信號燈集；消息同步表建立單元，用于建立消息同步表，所述消息同步表中 表項的數(shù)量與所述消息同步信號燈集中的消息同步信號燈的數(shù)量相同；消息同步表初始化單元，用于對所述消息同步表進行初始化。
全文摘要
本發(fā)明公開了一種消息的讀寫方法，包括將消息從生產(chǎn)者發(fā)送到消息隊列的步驟；根據(jù)所述消息的類型，查詢消息同步表，如果所述消息同步表中存在與所述消息的類型對應的記錄，則確認有對應的消費者的步驟；當有對應的消費者時，喚醒所述對應的消費者中的一個消費者的步驟；將所述消息發(fā)送給所述被喚醒的消費者的步驟。本發(fā)明還公開了一種消息的讀寫裝置，包括發(fā)送裝置、查詢裝置、喚醒裝置和將所述消息發(fā)送給所述被喚醒的消費者的裝置。本發(fā)明通過生產(chǎn)者根據(jù)消息的類型，在消息同步表中查詢有對應的消費者，并喚醒其中的一個消費者的方法，使得消費者不會被無謂喚醒，從而節(jié)省了CPU時間。
文檔編號G06F9/46GK101470636SQ20071030441
公開日2009年7月1日 申請日期2007年12月27日 優(yōu)先權日2007年12月27日
發(fā)明者宇 任, 朱律瑋, 強 鄒, 馬新群 申請人:北京東方通科技發(fā)展有限責任公司