專利名稱：一種分時處理的方法和裝置的制作方法
技術領域：
本發(fā)明涉及通訊技術領域，特別涉及一種分時處理的方法和裝置。
背景技術：
隨著因特網的高速發(fā)展，人們對網絡的可用性要求越來越高，特別是在響 應網絡拓樸變化方面，要求設備的收斂能力達到毫秒級別。這對設備的軟硬件 環(huán)境提出了新的要求。
在傳統(tǒng)的實現中，軟件需要解決業(yè)務分時處理的問題，也就是為了保證設 備的實時性，路由設備底層都采用了實時操作系統(tǒng)。但是，在目前的基礎設施 上進行業(yè)務處理時，如果業(yè)務處理需要耗費大量的時間，則會對正常處理流程 產生影響，比如有可能會影響正常的協議?；?、報文收發(fā)等。
為了解決上述問題，目前的軟件在實現上通?？紤]將業(yè)務劃分成多個子業(yè) 務，分別處理。
具體的，業(yè)務處理^^塊在完成一個子業(yè)務處理后，停止下一個子業(yè)務處理
(即主動讓出CPU資源)，同時激活一個定時器，等待一段時間后由定時器觸
發(fā)下一次子業(yè)務處理。
但這種方法中，每個業(yè)務處理模塊在進行完子業(yè)務處理后，都會激活一個 定時器，而每個業(yè)務處理模塊對應的定時器都是互相獨立的，這樣如果定時器 周期太小，而子業(yè)務處理的時間又大于定時器的時間，則其中一個業(yè)務處理才莫 塊會長時間進行子業(yè)務處理，其他業(yè)務處理模塊則必須等待很長時間，從而導
致某個模塊長時間占用CPU，而其他模塊無法獲得調度，嚴重時會導致其他協 議斷鏈；如果定時器如果上述定時器周期太大，則導致CPU無法充分利用， 從而影響協議收斂性能。綜上所述，目前的分時處理中，每個業(yè)務處理模塊的定時器都是互相獨立，
如果定時器的時間設置的不合理，會導致CPU無法充分利用，從而影響協議
收斂性能，嚴重時會導致協議斷鏈。

發(fā)明內容
本發(fā)明實施例提供一種分時處理的方法和裝置，用于提高在分時處理中， 資源的利用率以及協議收斂性能，并且避免由于分時處理引起的協議斷鏈資源。
本發(fā)明提供了一種分時處理的方法，該方法包括
策略執(zhí)行模塊將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請求列
表中；
所述策略執(zhí)行模塊根據預先設置的喚醒策略，從所述喚醒請求列表中確定 一個喚醒請求，并向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息，指示 業(yè)務處理模塊進行業(yè)務處理。
進一步地，在本發(fā)明中，還具有以下特點所述策略執(zhí)行模塊接收到的來
自業(yè)務處理模塊的喚醒請求之前還包括
所述業(yè)務處理模塊將需要處理的業(yè)務劃分為多個子業(yè)務； 所述策略執(zhí)行模塊向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息
后還包括
所述業(yè)務處理模塊在收到喚醒消息后，進行一個子業(yè)務處理； 所述業(yè)務處理;漠塊在完成一個子業(yè)務處理，且還有需要處理的子業(yè)務時，
向所述策略執(zhí)行模塊發(fā)送喚醒請求。
進一步地，在本發(fā)明中，還具有以下特點所述策略執(zhí)行模塊向發(fā)送確定
的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息后還包括
所述策略執(zhí)行模塊從所述喚醒請求列表中刪除確定的所述喚醒請求。 進一步地，在本發(fā)明中，還具有以下特點所述策略扭j亍;漠塊將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請求列表中包括
所述策略執(zhí)行模塊將收到的喚醒請求置于請求隊列中，在收到來自操作系 統(tǒng)的觸發(fā)信號后，從請求隊列中提取一個喚醒請求添加到喚醒請求列表中。
進一步地，在本發(fā)明中，還具有以下特點所述策略4丸行;漠塊從所述喚醒 請求列表中確定一個喚醒請求包括
所述策略執(zhí)行模塊從喚醒請求列表中提取出接收時間最早的喚醒請求，作 為確定的喚醒請求；或
所述策略執(zhí)行模塊從喚醒請求列表中提取出優(yōu)先級最高的喚醒請求，作為 確定的喚醒請求。
進一步地，在本發(fā)明中，還具有以下特點所述策略執(zhí)行模塊收到所述喚 醒請求后，向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息之前包括
所述策略執(zhí)行模塊確定當前收到的所述喚醒請求和上次收到的喚醒請求 的接收時間間隔；
所述策略執(zhí)行模塊將確定的接收時間間隔乘以預先設定的CPU空閑率， 得到發(fā)送間隔時間；
所述策略執(zhí)行模塊根據當前收到的所述喚醒請求的接收時間和確定的所 述發(fā)送間隔時間，確定發(fā)送喚醒消息時間；
所述策略執(zhí)行模塊向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息 包括
所述策略執(zhí)行模塊在發(fā)送喚醒消息時間到達后，向發(fā)送確定的喚醒請求的 業(yè)務處理模塊發(fā)送喚醒消息。
本發(fā)明還提供了一種分時處理的裝置，該裝置包括策略執(zhí)行模塊和多個業(yè) 務處理一莫塊，
所述業(yè)務處理模塊，用于向所述策略執(zhí)行模塊發(fā)送喚醒請求，在收到來自 所述策略執(zhí)行;漠塊的喚醒消息后，進行喚醒后的處理；
所述策略執(zhí)行模塊，用于將收到的所述喚醒請求添加到喚醒請求列表中，根據預先設置的喚醒策略，從所述喚醒請求列表中確定一個喚醒請求，并向發(fā) 送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息。
進一步地，在本發(fā)明中，還具有以下特點所述業(yè)務處理^t塊包括 請求模塊，用于向所述策略執(zhí)行模塊發(fā)送喚醒請求；
消息接收模塊，用于在收到來自所述策略執(zhí)行模塊的喚醒消息后，進行業(yè) 務處理；
所述策略執(zhí)行^f莫塊包括
添加模塊，用于將收到的所述喚醒請求添加到喚醒請求列表中； 喚醒請求確定模塊，用于根據預先設置的喚醒策略，從所述喚醒請求列表 中確定一個喚醒請求；
消息發(fā)送模塊，用于向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消
白
進一步地，在本發(fā)明中，還具有以下特點所述添加才莫塊用于 將收到的喚醒請求置于請求隊列中，在收到來自操作系統(tǒng)的觸發(fā)信號后，
從請求隊列中提取一個喚醒請求添加到喚醒請求列表中。
進一步地，在本發(fā)明中，還具有以下特點所述請求模塊用于 將需要處理的業(yè)務劃分為多個子業(yè)務后，向所述策略執(zhí)行模塊發(fā)送喚醒請
求，在所述業(yè)務處理模塊收到喚醒消息，完成一個子業(yè)務處理且還有需要處理
的子業(yè)務時，向所述策略執(zhí)行模塊發(fā)送喚醒請求。
進一步地，在本發(fā)明中，還具有以下特點所述喚醒請求確定模塊用于 從喚醒請求列表中提取出接收時間最早的喚醒請求，作為確定的喚醒請
求；或
從喚醒請求列表中提取出優(yōu)先級最高的喚醒請求，作為確定的喚醒請求。 進一步地，在本發(fā)明中，還具有以下特點所述策略執(zhí)行模塊還包括 時間確定模塊，用于確定當前收到的所述喚醒請求和上次收到的喚醒請求 的接收時間間隔，將確定的接收時間間隔乘以預先設定的CPU空閑率，得到發(fā)送間隔時間，根據當前收到的所述喚醒請求的接收時間和確定的所述發(fā)送間
隔時間，確定發(fā)送喚醒消息時間； 所述消息發(fā)送模塊用于
在發(fā)送喚醒消息時間到達后，向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送 喚醒消息。
進一步地，在本發(fā)明中，還具有以下特點所述策略執(zhí)行模塊還包括 刪除模塊，用于在所述消息發(fā)送模塊向業(yè)務處理模塊發(fā)送喚醒消息后，從 所述喚醒請求列表中刪除確定的所述喚醒請求。
本發(fā)明實施例策略執(zhí)行模塊將收到的來自業(yè)務處理模塊的喚醒請求添加 到喚醒請求列表中；所述策略執(zhí)行模塊根據預先設置的喚醒策略，從所述喚醒 請求列表中確定一個喚醒請求，并向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送 喚醒消息，指示業(yè)務處理模塊進行業(yè)務處理。由于每個業(yè)務處理模塊的調度都 有策略執(zhí)行模塊完成，使得每個業(yè)務處理模塊不再相互獨立，策略執(zhí)行模塊可 以根據預先設定的喚醒策略，選擇喚醒哪個業(yè)務處理才莫塊，從而能夠提高CPU 資源的利用率以及協議收斂性能，并且避免了由于分時處理引起的協議斷鏈。


圖1為本發(fā)明實施例分時處理的裝置結構示意圖； 圖2為本發(fā)明實施例分時處理的方法流程示意圖； 圖3為本發(fā)明實施例進行路由同步示意圖4為本發(fā)明實施例OSPF( Open Shortest Path First開放式最短路徑優(yōu)先) 協議模塊進行路由同步方法流程示意圖。
具體實施例方式
本發(fā)明實施例每個業(yè)務處理模塊都向策略執(zhí)行模塊發(fā)送喚醒請求，策略執(zhí) 行模塊根據預先設置的喚醒策略，向業(yè)務處理模塊發(fā)送喚醒消息，對業(yè)務處理模塊進行調度，指示業(yè)務處理模塊進行業(yè)務處理。由于每個業(yè)務處理模塊的調 度都有策略執(zhí)行模塊完成，使得每個業(yè)務處理模塊不再相互獨立，策略執(zhí)行模 塊可以根據預先設定的喚醒策略，選擇喚醒哪個業(yè)務處理才莫塊，從而能夠提高 CPU資源的利用率以及協議收斂性能。
其中，本發(fā)明實施例的業(yè)務可以是高層信令的業(yè)務，也可以是底層信令的 業(yè)務，還可以是其他類型的業(yè)務。
具體包括但不限于下列業(yè)務中的一種或多種 路由同步業(yè)務、發(fā)送數據業(yè)務。
下面結合說明書附圖對本發(fā)明實施例作進一步詳細描述。 如圖1所示，本發(fā)明實施例分時處理的裝置包括多個業(yè)務處理模塊和策 略執(zhí)行模塊。
業(yè)務處理模塊IO,用于向策略執(zhí)行模塊20發(fā)送喚醒請求，在收到來自策 略執(zhí)行模塊20的喚醒消息后，進行喚醒后的處理。
其中，業(yè)務處理模塊IO還可以進一步包括請求模塊100和消息接收模 塊110。
請求模塊100，用于向策略執(zhí)行模塊20發(fā)送喚醒請求。 在具體實施過程中，請求模塊IOO將需要處理的業(yè)務劃分為多個子業(yè)務后， 向策略執(zhí)行模塊20發(fā)送喚醒請求，在消息接收才莫塊110收到喚醒消息，完成 一個子業(yè)務處理且還有需要處理的子業(yè)務時，向策略執(zhí)行模塊20發(fā)送喚醒請求。
請求模塊IOO將需要處理的業(yè)務劃分為多個子業(yè)務后，可以先不向策略執(zhí) 行模塊20發(fā)送喚醒請求，而是先觸發(fā)消息接收才莫塊110對一個子業(yè)務進行處 理，在消息接收模塊110完成一個子業(yè)務處理后，再向策略執(zhí)行模塊20發(fā)送 喚醒請求。
消息接收模塊IIO,用于在收到來自策略執(zhí)行模塊20的喚醒消息后，進行 業(yè)務處理。比如需要查找100個路由地址，則可以先查找10個路由地址，然后停 止處理(即主動停止本次工作，讓出CPU資源)，等收到喚醒消息后，再查找 IO個路由地址；也可以設定一時間，比如lms，則查找時間到了 lms，停止處 理，等收到喚醒消息后，再查找。
上面只是舉了兩個劃分業(yè)務的方式，需要說明的是，本實施例并不局限于 上述兩種劃分方式，其他劃分方式同樣適用本實施例。
策略執(zhí)行模塊20,用于將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒 請求列表中，根據預先設置的喚醒策略，從喚醒請求列表中確定一個喚醒請求， 并向發(fā)送確定的喚醒請求的業(yè)務處理^^塊發(fā)送喚醒消息。
其中，策略執(zhí)行模塊20還可以進一步包括添加模塊200、喚醒請求確定 模塊210和消息發(fā)送模塊220。
添加模塊200,用于將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請 求列表中。
在具體實施過程中，可以設置模塊的優(yōu)先級，較佳的是將策略執(zhí)行模塊20 的優(yōu)先級設置為最低，這樣在收到喚醒請求后先不進行處理，而是等待操作系 統(tǒng)的觸發(fā)信號，在等待過程中還有可能收到喚醒請求，則添加模塊200將收到 的喚醒請求置于請求隊列中，在收到來自操作系統(tǒng)的觸發(fā)信號后，從請求隊列 中提取一個喚醒請求添加到喚醒請求列表中。
在提取喚醒請求時，可以根據收到的喚醒請求的接收時間確定提取哪個喚 醒請求，比如可以提取接收時間最早的喚醒請求。
喚醒請求確定模塊210,用于根據預先設置的喚醒策略，從喚醒請求列表 中確定一個喚醒請求。
喚醒策略可以根據需要進行設置，較佳的可以設置一個初始策略，如果沒 有設置新的策略，則根據初始策略進行處理；如果設置了多個策略，還可以根 據策略的優(yōu)先級，選擇優(yōu)先級高的策略進行處理。
喚醒策略包括但不限于下列策略中的一種或多種先來先服務策略、喚醒請求優(yōu)先級策略(即發(fā)送喚醒請求的模塊的優(yōu)先級)。
其中，如果采用先來先服務策略，則喚醒請求確定;^莫塊210從喚醒請求列
表中提取出接收時間最早的喚醒請求，作為確定的喚醒請求；
如果釆用喚醒請求優(yōu)先級策略，則喚醒請求確定模塊210從喚醒請求列表
中提取出優(yōu)先級最高的喚醒請求，作為確定的喚醒請求。
消息發(fā)送模塊220,用于向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒 消息。
其中，為了使網絡能夠安全運行，本發(fā)明實施例還可以預留部分處理能力， 即要求CPU使用率不高于設定的閾值，也就是在一段時間內，CPU不會一直 處于滿負荷的狀態(tài)工作，這樣可以保證CPU有能力處理關鍵業(yè)務，則策略執(zhí) 行模塊20還可以進一步包括時間確定模塊230。
時間確定模塊230,用于確定當前收到的喚醒請求和上次收到的喚醒請求 的接收時間間隔，將確定的接收時間間隔乘以預先設定的CPU空閑率，得到 發(fā)送間隔時間，根據當前收到的喚醒請求的接收時間和確定的發(fā)送間隔時間， 確定發(fā)送喚醒消息時間。
在具體實施過程中，可以預先設定CPU使用率，則CPU空閑率-1-CPU 使用率。
比如當前收到的喚醒請求的接收時間為13點1分O秒，上次收到的喚醒
請求時間為13點0分50秒，則4妄收時間間隔為10秒。
CPU使用率為80。/。，則發(fā)送間隔時間為10x (1-80%) =2秒。 則發(fā)送喚醒消息時間=當前收到的喚醒請求的接收時間+發(fā)送間隔時間
=13點1分2秒。
消息發(fā)送模塊220在發(fā)送喚醒消息時間到達后，向發(fā)送確定的喚醒請求的 業(yè)務處理模塊發(fā)送喚醒消息。
由于可以在收到喚醒請求和發(fā)送喚醒消息之間有一定的時間間隔，從而保證CPU在一段時間內不會一直處于滿負荷的狀態(tài)工作，進而保證CPU使用率
低于閾值。
如果沒有確定發(fā)送喚醒消息時間，則消息發(fā)送模塊220可以在確定一個喚 醒請求后，馬上發(fā)送喚醒消息。
其中，策略執(zhí)行模塊20還可以進一步包括刪除模塊240。
刪除模塊240,用于在消息發(fā)送模塊220向業(yè)務處理模塊發(fā)送喚醒消息后，
從喚醒請求列表中刪除喚醒請求確定模塊210確定的喚醒請求。 如圖2所示，本發(fā)明實施例分時處理的方法包括下列步驟 步驟300、策略執(zhí)行模塊將收到的來自業(yè)務處理模塊的喚醒請求添加到喚
醒請求列表中。
在具體實施過程中，可以設置模塊的優(yōu)先級，較佳的是將策略執(zhí)行模塊的 優(yōu)先級設置為最低，這樣在收到喚醒請求后先不進行處理，而是等待操作系統(tǒng) 的觸發(fā)信號，在等待過程中還有可能收到喚醒請求，則策略執(zhí)行模塊將收到的 喚醒請求置于請求隊列中，在收到來自操作系統(tǒng)的觸發(fā)信號后，從請求隊列中 提取一個喚醒請求添加到喚醒請求列表中。
在提取喚醒請求時，可以根據收到的喚醒請求的接收時間確定提取哪個喚 醒請求，比如可以提取結合搜時間最早的喚醒請求。
步驟301、策略執(zhí)行模塊根據預先設置的喚醒策略，從喚醒請求列表中確 定一個喚醒請求。
喚醒策略可以根據需要進行設置，較佳的可以設置一個初始策略，如果沒 有設置新的策略，則根據初始策略進行處理；如果設置了多個策略，還可以根 據策略的優(yōu)先級，選擇優(yōu)先級高的策略進行處理。
喚醒策略包括但不限于下列策略中的一種或多種
先來先服務策略、喚醒請求優(yōu)先級策略(即發(fā)送喚醒請求的模塊的優(yōu)先級)。
其中，如果釆用先來先服務策略，則策略執(zhí)行模塊從喚醒請求列表中提取出接收時間最早的喚醒請求，作為確定的喚醒請求；
如果采用喚醒請求優(yōu)先級策略，則策略執(zhí)行模塊從喚醒請求列表中提取出 優(yōu)先級最高的喚醒請求，作為確定的喚醒請求。
岳孤* 309 紫ffi^抽； 千J^地劣t、44石il * AA p魚艇；備杏'、+么々1、碟7t貧it密W p魚鵬
消息，指示業(yè)務處理模塊進行業(yè)務處理。
其中，在步驟300之前還可以進一步包括 業(yè)務處理模塊將需要處理的業(yè)務劃分為多個子業(yè)務。
在具體實施過程中，業(yè)務處理模塊將需要處理的業(yè)務劃分為多個子業(yè)務 后，可以先不向策略執(zhí)行模塊發(fā)送喚醒請求，而是先對一個子業(yè)務進行處理， 在完成一個子業(yè)務處理后，再向策略執(zhí)行模塊發(fā)送喚醒請求。
則步驟302之后還可以進一步包括
步驟303、業(yè)務處理才莫塊在收到喚醒消息后，進^f于一個子業(yè)務處理。
步驟304、業(yè)務處理模塊在完成一個子業(yè)務處理，且還有需要處理的子業(yè) 務時，向策略執(zhí)行模塊發(fā)送喚醒請求。
比如需要查找100個路由地址，則可以先查找10個路由地址，然后停 止處理(即主動停止本次工作，讓出CPU資源)，等收到喚醒消息后，再查找 IO個路由地址；也可以i殳定一時間，比如lms，則查找時間到了 lms,停止處 理，等收到喚醒消息后，再查找。
上面只是舉了兩個劃分業(yè)務的方式，需要說明的是，本實施例并不局限于 上述兩種劃分方式，其他劃分方式同樣適用本實施例。
其中，為了使網絡能夠安全運行，本發(fā)明實施例還可以預留部分處理能力， 即要求CPU使用率不高于設定的閾值，也就是在一段時間內，CPU不會一直 處于滿負荷的狀態(tài)工作，這樣可以保證CPU有能力處理關鍵業(yè)務，則步驟301 和步驟302之間還可以進一步包括
步驟S1 、策略執(zhí)行模塊確定當前收到的喚醒請求和上次收到的喚醒請求的 接收時間間隔；步驟S2、策略執(zhí)行模塊將確定的接收時間間隔乘以預先設定的CPU空閑 率，得到發(fā)送間隔時間；
步驟S3、策略執(zhí)行模塊根據當前收到的喚醒請求的接收時間和確定的發(fā)送 間隔時間，確定歲:送喚醒消息時間
在具體實施過程中，可以預先設定CPU使用率，則CPU空閑率-1-CPU
使用率。
比如當前收到的喚醒請求的接收時間為13點1分0秒，上次收到的喚醒
請求時間為13點0分50秒，則接收時間間隔為10秒。
CPU使用率為80。/。，則發(fā)送間隔時間為10x (1-80%) =2秒。 則發(fā)送喚醒消息時間=當前收到的喚醒請求的接收時間+發(fā)送間隔時間
- 13點1分2秒。
則步驟302中，策略執(zhí)行模塊在發(fā)送喚醒消息時間到達后，向發(fā)送確定的 喚醒請求的業(yè)務處理^f莫塊發(fā)送喚醒消息。
由于可以在收到喚醒請求和發(fā)送喚醒消息之間有一定的時間間隔，從而保 證CPU在一段時間內不會一直處于滿負荷的狀態(tài)工作，進而保證CPU使用率 低于閾值。
如果沒有確定發(fā)送喚醒消息時間，則步驟302中，策略執(zhí)行模塊可以在確 定一個喚醒請求后，馬上發(fā)送喚醒消息。
其中，步驟302之后還可以進一步包括
策略執(zhí)行模塊從喚醒請求列表中刪除步驟301中確定的喚醒請求。 如圖3所示，本發(fā)明實施例進行路由同步示意圖中，OSPF模塊和BGP (Border Gateway Protocol邊界網關協議)模塊為兩個路由協議模塊。
OSPF模塊和BGP模塊各自計算出路由數目，并需要同步給路由總控模塊 進行匯總決策。
在大型網絡中，路由數目非常巨大，如果一個模塊全部統(tǒng)計完需要花費大 量時間，這樣會造成其他模塊不能進行處理。假設本發(fā)明實施例喚醒策略為先來先服務。
OSPF模塊和BGP模塊首先會向策略執(zhí)行模塊發(fā)送喚醒請求。
策略執(zhí)行模塊在收到來自OSPF模塊和BGP模塊的喚醒請求后，確定哪 個模塊的喚醒請求接收時間最早，假設OSPF模塊發(fā)送的喚醒請求接收時間早， 則策略執(zhí)行模塊向OSPF模塊發(fā)送喚醒消息。
OSPF模塊收到喚醒消息后，進行一個子業(yè)務處理，在確定還有子業(yè)務需 要處理，向策略執(zhí)行模塊發(fā)送喚醒請求。
策略執(zhí)行模塊在收到OSPF模塊的喚醒請求后，確定BGP模塊發(fā)送的喚 醒請求接收時間早，則策略執(zhí)行模塊向BGP模塊發(fā)送喚醒消息。
BGP模塊收到喚醒消息后，進行一個子業(yè)務處理，在確定還有子業(yè)務需要 處理，向策略執(zhí)行模塊發(fā)送喚醒請求。
這樣就形成了 OSPF模塊和BGP模塊交替處理子業(yè)務。
如圖4所示，本發(fā)明實施例OSPF協議模塊進行路由同步方法包括下列步
驟
步驟400、 OSPF協議模塊在設定的時間內進行路由同步，并向路由總控 模塊發(fā)送同步數據消息。
步驟401、 OSPF協議模塊查看是否進行完所有的路由同步，如果是，則 讓出CPU資源，并執(zhí)行步驟408;否則，執(zhí)行步驟402。
步驟402、 OSPF協議模塊向策略執(zhí)行模塊發(fā)送喚醒請求，并停止本次處 理，讓出CPU資源。
步驟403、路由總控模塊在OSPF協議模塊讓出CPU資源后，對接收到的 同步數據消息進行處理，處理完成后，讓出CPU資源。
步驟404、策略執(zhí)行模塊將收到的喚醒請求置于請求隊列中。
步驟405、策略執(zhí)行模塊在收到操作系統(tǒng)的觸發(fā)信號后，從請求隊列中提 取出喚醒請求，并添力口到喚醒請求列表中。
步驟406、策略執(zhí)行模塊根據先來先服務策略，從喚醒請求列表中確定OSPF協議模塊發(fā)送的喚醒請求，向OSPF協議模塊發(fā)送喚醒消息，并從喚醒 請求列表中刪除確定的喚醒請求。
步驟407、 OSPF協議模塊收到喚醒消息后，在設定的時間內進行路由同
步，并向路由總控模塊發(fā)送同步數據消息，返回步驟401。
步驟408、 OSPF協議模塊結束同步處理。
其中，步驟403和步驟404之間沒有時序關系，也就是說，可以先執(zhí)行步 驟403再執(zhí)行步驟404,也可以執(zhí)行步驟404再扭J亍步驟403，還可以同時執(zhí) 行步驟403和步驟404。
從上述實施例中可以看出本發(fā)明實施例策略執(zhí)行模塊將收到的來自業(yè)務 處理模塊的喚醒請求添加到喚醒請求列表中；所述策略執(zhí)行模塊根據預先設置 的喚醒策略，從所述喚醒請求列表中確定一個喚醒請求，并向發(fā)送確定的喚醒 請求的業(yè)務處理模塊發(fā)送喚醒消息，指示業(yè)務處理模塊進行業(yè)務處理。由于每 個業(yè)務處理模塊的調度都有策略執(zhí)行模塊完成，使得每個業(yè)務處理模塊不再相 互獨立，策略執(zhí)行模塊可以根據預先設定的喚醒策略，選擇喚醒哪個業(yè)務處理 模塊，從而能夠提高CPU資源的利用率以及協議收斂性能，并且避免了由于 分時處理引起的協議斷鏈。
明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及 其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1、一種分時處理的方法，其特征在于，該方法包括策略執(zhí)行模塊將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請求列表中；所述策略執(zhí)行模塊根據預先設置的喚醒策略，從所述喚醒請求列表中確定一個喚醒請求，并向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息，指示業(yè)務處理模塊進行業(yè)務處理。
2、 如權利要求1所述的方法，其特征在于，所述策略執(zhí)行模塊接收到的 來自業(yè)務處理模塊的喚醒請求之前還包括所述業(yè)務處理模塊將需要處理的業(yè)務劃分為多個子業(yè)務； 所述策略執(zhí)行模塊向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息 后還包括所述業(yè)務處理模塊在收到喚醒消息后，進行一個子業(yè)務處理； 所述業(yè)務處理;漠塊在完成一個子業(yè)務處理，且還有需要處理的子業(yè)務時， 向所述策略執(zhí)行^^莫塊發(fā)送喚醒請求。
3、 如權利要求1所述的方法，其特征在于，所述策略執(zhí)行模塊向發(fā)送確 定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息后還包括所述策略執(zhí)行模塊從所述喚醒請求列表中刪除確定的所述喚醒請求。
4、 如權利要求1或2或3所述的方法，其特征在于，所述策略執(zhí)行模塊 將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請求列表中包括所述策略執(zhí)行模塊將收到的喚醒請求置于請求隊列中，在收到來自操作系 統(tǒng)的觸發(fā)信號后，從請求隊列中提取一個喚醒請求添加到喚醒請求列表中。
5、 如權利要求1或2或3所述的方法，其特征在于，所述策略執(zhí)行模塊 從所述喚醒請求列表中確定一個喚醒請求包括所述策略執(zhí)行模塊從喚醒請求列表中提取出接收時間最早的喚醒請求，作 為確定的喚醒請求；或所述策略執(zhí)行才莫塊從喚醒請求列表中提取出優(yōu)先級最高的喚醒請求，作為 確定的喚醒請求。
6、 如權利要求1或2或3所述的方法，其特征在于，所述策略執(zhí)行模塊 收到所述喚醒請求后，向發(fā)送確定的喚醒請求的業(yè)務處理^t塊發(fā)送喚醒消息之 前包括所述策略執(zhí)行模塊確定當前收到的所述喚醒請求和上次收到的喚醒請求 的接收時間間隔；所述策略執(zhí)行模塊將確定的接收時間間隔乘以預先設定的CPU空閑率， 得到發(fā)送間隔時間；所述策略執(zhí)行模塊根據當前收到的所述喚醒請求的接收時間和確定的所 述發(fā)送間隔時間，確定發(fā)送喚醒消息時間；所述策略執(zhí)行模塊向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息 包括所述策略執(zhí)行模塊在發(fā)送喚醒消息時間到達后，向發(fā)送確定的喚醒請求的 業(yè)務處理模塊發(fā)送喚醒消息。
7、 一種分時處理的裝置，其特征在于，該裝置包括策略執(zhí)行模塊和多個 業(yè)務處理模塊，所述業(yè)務處理模塊，用于向所述策略執(zhí)行模塊發(fā)送喚醒請求，在收到來自 所述策略執(zhí)行模塊的喚醒消息后，進行喚醒后的處理；所述策略執(zhí)行模塊，用于將收到的所述喚醒請求添加到喚醒請求列表中， 根據預先設置的喚醒策略，從所述喚醒請求列表中確定一個喚醒請求，并向發(fā) 送確定的喚醒請求的業(yè)務處理;漠塊發(fā)送喚醒消息。
8、 如權利要求7所述的裝置，其特征在于，所述業(yè)務處理模塊包括 請求模塊，用于向所述策略執(zhí)行模塊發(fā)送喚醒請求；消息接收模塊，用于在收到來自所述策略執(zhí)行模塊的喚醒消息后，進行業(yè) 務處理；所述策略執(zhí)行模塊包括添加模塊，用于將收到的所述喚醒請求添加到喚醒請求列表中； 喚醒請求確定模塊，用于根據預先設置的喚醒策略，從所述喚醒請求列表 中確定一個喚醒i青求；消息發(fā)送模塊，用于向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消自
9、 如權利要求8所述的裝置，其特征在于，所述添加模塊用于 將收到的喚醒請求置于請求隊列中，在收到來自操作系統(tǒng)的觸發(fā)信號后，從請求隊列中提取一個喚醒請求添加到喚醒請求列表中。
10、 如權利要求8所述的裝置，其特征在于，所述請求模塊用于 將需要處理的業(yè)務劃分為多個子業(yè)務后，向所述策略執(zhí)行模塊發(fā)送喚醒請求，在所述業(yè)務處理模塊收到喚醒消息，完成一個子業(yè)務處理且還有需要處理 的子業(yè)務時，向所述策略執(zhí)行模塊發(fā)送喚醒請求。
11、 如權利要求8所述的裝置，其特征在于，所述喚醒請求確定模塊用于 從喚醒請求列表中提取出接收時間最早的喚醒請求，作為確定的喚醒請求；或從喚醒請求列表中提取出優(yōu)先級最高的喚醒請求，作為確定的喚醒請求。
12、 如權利要求8至11任一權利要求所述的裝置，其特征在于，所述策 略執(zhí)行模塊還包括時間確定模塊，用于確定當前收到的所述喚醒請求和上次收到的喚醒請求 的接收時間間隔，將確定的接收時間間隔乘以預先設定的CPU空閑率，得到 發(fā)送間隔時間，根據當前收到的所述喚醒請求的接收時間和確定的所述發(fā)送間 隔時間，確定發(fā)送喚醒消息時間；所述消息發(fā)送模塊用于在發(fā)送喚醒消息時間到達后，向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送 喚醒消息。
13、如權利要求8至11任一權利要求所述的裝置，其特征在于，所述策略執(zhí)行模塊還包括刪除模塊，用于在所述消息發(fā)送模塊向業(yè)務處理模塊發(fā)送喚醒消息后，從 所述喚醒請求列表中刪除確定的所述喚醒請求。
全文摘要
本發(fā)明涉及通訊技術領域，特別涉及一種分時處理的方法和裝置，用以解決現有技術中存在的分時處理中，每個業(yè)務處理模塊的定時器都是互相獨立，如果定時器的時間設置的不合理，會導致CPU無法充分利用，從而影響協議收斂性能，嚴重時會導致協議斷鏈的問題。本發(fā)明實施例的方法包括策略執(zhí)行模塊將收到的來自業(yè)務處理模塊的喚醒請求添加到喚醒請求列表中；所述策略執(zhí)行模塊根據預先設置的喚醒策略，從所述喚醒請求列表中確定一個喚醒請求，并向發(fā)送確定的喚醒請求的業(yè)務處理模塊發(fā)送喚醒消息，指示業(yè)務處理模塊進行業(yè)務處理。采用本發(fā)明實施例的方法能夠提高CPU資源的利用率以及協議收斂性能，并且避免由于分時處理引起的協議斷鏈。
文檔編號G06F9/46GK101446911SQ200910000410
公開日2009年6月3日 申請日期2009年1月6日 優(yōu)先權日2009年1月6日
發(fā)明者吳道揆 申請人:中興通訊股份有限公司