多重呼叫處理線程處理方法
2023-10-04 16:54:39
專利名稱：多重呼叫處理線程處理方法
技術領域：
本發明涉及一種多重呼叫處理線程處理方法，適用於例如VoIP伺服器，該VoIP伺服器適用搭載了TSS(時間分配系統)調度程序的通用多任務OS。
背景技術：
就處理大量VoIP信號的VoIP伺服器而言，VoIP軟開關是適用的。在適用該VoIP軟開關的、VoIP信號從多個用戶同時到達的系統中，使用Linux(UNIX；註冊商標)、Windows(註冊商標)等通用多任務OS，即便在單一處理器環境下，在具有多個進程(用戶的呼叫處理請求)的情況下，通過分割並分配CPU使用時間，採用看上去就如同同時處理一樣的TSS調度程序。關於TSS調度程序，在各種文獻中(例如參照非專利文獻1)有所記載。
另外，現有的硬體或作業系統最適於在執行基於該TSS調度程序的計算時高速地進行操作。
非專利文獻1澤田勉、澤田綾子、永井正武共著，《理解Linux與Windows用的OS入門》，共立出版株式會社2003年11月發行，126-130頁發明內容本發明所要解決的問題TSS調度程序向進程分配量子(規定時間)而執行。通常，量子的值為8-10m秒左右。在該時間單位下，從CPU的處理中卸下處理過程中的進程，將CPU轉向其它進程。此時，與處理過程中的進程相關的CPU高速緩衝存儲器被刷新(フラッシュ)，並再次構築與其它進程相關的高速緩衝存儲器。
但是，一般的呼叫控制信號分別由非常短的數據分組構成，為了處理各自的事件而使用的時間是比量子短得多的時間，在如此短的時間內，完成了處理。為此，可通過OS的調整等將量子設定為很短，但由於基於調度的CPU高速緩衝存儲器刷新多次發生，從而CPU的性能明顯降低。
並且，在實現有狀態(ステ一トフル)的VoIP呼叫控制的情況下，各事件具有關聯性，事件處理在各狀態下被左右。利用圖2來說明在一般的多線程環境下實現此時的處理流程的呼叫控制應用程式(VoIP呼叫控制進程)的實例。
若輸入了呼叫信號(數據分組)，則在基於核心程序(的調度程序)內的排隊的等待時間之後，從各輸入部(分組接收部)生成呼叫處理事件隊列對象，並對事件進行排隊(1、2、3)。向每個呼叫處理事件隊列分配線程，利用事件驅動來生成線程或分配事先已生成的線程。該事件隊列成為針對每個呼叫組而生成的對象，在輸入指向已有對象的事件的情況下，僅使指向該對象排隊(4)。在此利用事件驅動來生成線程的方式中，由於線程被分配給各個事件，所以希望縮短事件處理的響應時間。但是，在呼叫事件處理時間短於系統調度程序的量子的情況下，為了將CPU轉到其它的線程操作，無用的上下文切換成為必要的。還存在系統不能將CPU迅速地轉到其它線程的情況，從而不能充分利用基於CPU的、用戶程序的可執行時間。
之後，在各個呼叫對象執行呼叫處理的過程中，頻繁地發生生成(5)、變更(6)、或閱覽(7)作為有狀態數據區域的呼叫處理的資源的操作。這些操作表示有多個對象對一個有狀態數據進行訪問。此時，為了數據的整合性不因線程的再入而被破壞，有必要實現對數據的排他控制。這就是在線程同時對同一區域進行訪問的情況下，僅使唯一的線程操作，而使其它的線程停止操作。最簡單的是，為了高速地實現排他控制，存在功能提供有幾乎全部OS的Mutex(互斥鎖定)等排他基本單元(primitive)，但使用該排他基本單元的排他控制在CPU被轉到其它線程之前，依賴於由核心程序內的調度程序進行的分配器處理，結果，導致通過量大幅度下降。
另外，通過按事件驅動而生成多個線程，能夠由系統的TSS調度程序來提高服務交互性，但另一方面，不能預測各呼叫事件執行契機的發生時間。
圖3表示與由一般的TSS調度程序執行阻塞的事件處理時的執行定時相關的時間表實例。為簡單起見，圖3的實例假設一個處理器系統中儘可能沒有事件處理以外的其它處理。
若各事件處理結束，則發生將CPU轉到其它進程的調度(DP)。另外，為了在量子Q結束後不繼續處理而強制地產生中斷，並隔著調度發生了事件處理的切換(圖3中的自事件處理2至3)。由此，導致了無意的調度。如上所述，在發生調度時，由於要重新構築CPU內的高速緩存，而與用戶進程處理的等待時間(latency)(調用)相關。另外，在執行針對每個線程的優先控制時，當事件處理2在處理中途被調度時，其它事件處理3被中斷，從而打亂了順序性。
因此，希望存在一種使不依賴於OS中TSS調度程序的安裝、最大限度地使用CPU、並執行呼叫處理事件的處理成為可能的多重呼叫處理任務處理方法。
解決問題的手段為了解決上述問題，本發明的第1方面為一種由單個CPU按照在存儲器上展開的呼叫處理程序來執行阻塞發生的呼叫處理事件的多重呼叫處理線程處理方法，其特徵在於在安裝有TSS調度程序的OS與呼叫處理應用程式之間，插入呼叫處理事件調度程序，上述呼叫處理事件調度程序在上述TSS調度程序管理的CPU執行時間內，裝入並執行對1個或多個呼叫處理事件的處理。
另外，本發明的第2方面為一種由單個CPU按照在存儲器上展開的呼叫處理程序來執行阻塞發生的呼叫處理事件的多重呼叫處理線程處理方法，其特徵在於在安裝有TSS調度程序的OS與呼叫處理應用程式之間，設置呼叫處理事件引擎，該呼叫處理事件引擎執行上下文的連結/管理、順序控制、呼叫處理上下文的掛起檢驗(ハングチェック)，上述呼叫處理事件引擎具有呼叫處理事件調度程序，該呼叫處理事件調度程序在上述TSS調度程序管理的CPU執行時間內，裝入並執行對1個或多個呼叫處理事件的處理。
發明效果依據本發明的多重呼叫處理線程處理方法，呼叫處理事件調度程序在TSS調度程序管理的CPU執行時間內，裝入並執行對一個或多個呼叫處理事件的處理，所以可不依賴於OS中TSS調度程序的安裝、最大限度地使用CPU、並執行呼叫處理事件的處理。
圖1是實施方式的多重呼叫處理線程處理方法的執行環境說明圖。
圖2是表示實現有狀態的VoIP呼叫控制的、現有VoIP呼叫控制進程實例的說明圖。
圖3是表示與由一般的TSS調度程序執行阻塞的事件處理時的執行定時相關的時間表實例的說明圖。
圖4是表示與執行在將實施方式的呼叫處理事件調度程序與TSS調度程序合用時的阻塞的事件處理的情況下的執行定時相關的時間表實例的說明圖。
圖5是表示依據實施方式的用戶執行用線程的基本操作流程圖。
圖6是表示依據實施方式的掛起檢驗線程的操作流程圖。
圖7是表示基於依據實施方式的呼叫處理事件引擎的CA(呼叫代理)進程的構造實例的說明圖。
圖8是表示依據實施方式的呼叫處理事件調度程序的正常序列的序列圖。
圖9是表示依據實施方式的呼叫處理事件調度程序的異常序列的序列圖。
符號說明
1...多重呼叫處理線程處理裝置、10...硬體、20...通用多任務OS、21...核心程序、22...TSS調度程序、30...呼叫處理事件引擎、31...呼叫處理事件調度程序、40...VoIP應用程式具體實施方式
(A)實施方式下面，參照附圖來詳述依據本發明的多重呼叫處理任務外理方法的一種實施方式。
安裝了本實施方式的多重呼叫處理任務處理方法的多重呼叫處理任務處理裝置例如適用於處理大量VoIP信號(例如80萬條線路)的呼叫代理(電話交換系統的一種)中，硬體上與一般的呼叫代理一樣。即，具備CPU、存儲器、內置HDD等大容量存儲裝置、鍵盤、滑鼠、顯示器、通信接口部等，CPU經系統總線連接於存儲器，並經系統總線和輸入輸出設備，與大容量存儲裝置、鍵盤、滑鼠、顯示器、通信接口部等連接。
該多重呼叫處理任務處理裝置例如適用Linux·Windows等通用多任務OS。如上所述，通用多任務OS在核心程序內具有TSS調度程序。
多重呼叫處理任務處理裝置1如圖1所示，除通用多任務OS20中的核心程序21內的TSS調度程序22之外，還包括位於用戶層中的、具有調度程序功能(呼叫處理事件調度程序31)的呼叫處理事件引擎30，從調度程序功能面看，TSS調度程序22經事件引擎30，將基於VoIP應用程式40的線程作為處理對象。換言之，事件調度程序31是在核心程序21的TSS調度程序22上操作的上下文。
圖4表示根據實施方式的多重呼叫處理任務處理裝置1執行呼叫處理事件時的時間表實例，主要示出呼叫處理事件調度程序31的處理圖象。圖4是與依據現有技術的圖3相對應的附圖。
呼叫處理事件調度程序31連結進行隊列管理並執行順序控制的多個處理時間短的事件，使用一次分配的最大CPU時間(TSS調度程序22提供的量子)Q，實施呼叫處理事件的處理。圖4的實例中，僅在事件處理1中埋入CPU時間Q，呼叫處理事件調度程序31在該CPU時間Q內，繼續處理事件處理2(的前半部分)。在各事件處理的切換期間(圖4中的『Ev切換』)，呼叫處理事件調度程序31的控制處理被中斷，但馬上執行下一事件處理。由此，由於在各事件處理之間不執行對與調度(圖4中的『DP』)或呼叫控制處理無關的其它進程(圖4中的『其它處理』)的處理，所以在相同的CPU處理時間Q內可處理更多的事件。另外，調度是由TSS調度程序22產生的。
這裡，由於沒有發生無意的調度，所以可最大限度地活用CPU高速緩存，有助於進一步高速化。另外，依據本實施方式的圖4與依據現有技術的圖3針對同樣的事件處理系列的情況，但現有技術中5次的調度次數在本實施方式中被減少為3次。
下面，說明本實施方式中的呼叫處理事件調度程序31的控制操作。
若向調度程序31輸入一個事件，則排成用於順序控制的隊列。這裡，根據所排的事件個數來判定事件是否阻塞，在確認發生阻塞的情況下，將該情況記錄在調度程序31中。
在調度程序31內，最低生成一個監視線程，以監視事件隊列和正在執行事件處理的線程。若事件被輸入並被排隊，則利用該監視線程生成用於實施新的事件處理的線程(用戶執行用線程)。
圖5表示用戶執行用線程的基本操作。用戶執行用線程在生成與所輸入的事件相關的上下文之後(S101)，確認有無事件(S102)，若存在事件，則選擇執行的用戶(例如後述的呼叫處理對象組)(S103)，在執行該用戶的處理後(S104)，返回上述確認有無事件的步驟。在該用戶處理的執行過程中，生成適當事件。另外，還執行後述的用於掛起檢驗的時間計測等。
重複步驟S102-S104構成的循環，當存在經過了TSS調度程序22的最大CPU時間Q的調度時，該循環處理被中斷，並通過TSS調度程序22對自己的調度而重新開始。由此，實現圖4所示的、在最大CPU時間Q內的事件切換。
在判斷出由於上述進行排隊的其它線程而陷入阻塞狀態的情況下，監視線程選擇是生成新的事件處理還是在生成新的監視線程後自然地切換到事件處理線程。監視線程切換到事件處理線程後原樣操作的理由在於，在阻塞時，難以確保用於生成新的線程的資源，以及難以保證生成可確實地操作的線程。另外，由於監視線程一方的線程優先級高，所以可更確實地執行事件處理，剪取隊列。
由監視線程進行的、對事件處理線程的監視通過各事件的執行時間計測來進行掛起檢驗。事件處理線程在切換各事件處理時向事件調度程序31中記錄時間戳。監視線程根據該時間戳來計算執行各事件處理所需的時間，並判定是否在閾值範圍內。在各事件處理內部產生無限循環等的情況下，經過閾值的對應時間後，再次生成新的事件處理線程。若在單位時間內發生多次該事件處理線程的再生成，則視為死鎖(デッドロック)，進行進程的重新開始請求。
圖6用流程圖來表示監視線程(掛起檢驗線程)的這種操作。監視線程(掛起檢驗線程)在生成掛起檢驗用的上下文之後(S201)，判定有無執行中用戶(執行過程中的事件處理事件)(S202)，若存在執行中用戶，則僅在執行中用戶的範圍內選擇執行中用戶(S203)，並確認沒有時間突發(タイムバ一スト)(S204)。然後，若有時間突發的執行中用戶，則生成對這樣的用戶的用戶處理執行用的上下文(S205)，返回上述步驟S202。
通過導入上述呼叫處理事件調度程序31，可不依賴於OS20中的TSS調度程序22的安裝地最大限度使用CPU和執行呼叫處理事件時的處理。
由於控制線程數以僅生成在所請求的呼叫事件處理中所需的線程數，即便在TSS調度程序22的環境下，也可以使產生保持有狀態數據的呼叫事件彼此不發生上下文衝突地高速進行處理。另外，可將系統內的線程數抑制到最小限度，抑制發生由核心程序21的調度程序22進行的不必要的調度處理，結果，可縮短呼叫事件執行契機的定時，確保服務交互性。
本實施方式的呼叫處理事件引擎30是呼叫代理(電話交換系統)等高速執行阻塞產生的呼叫處理事件用的部件，用於執行上下文的連結/管理、順序控制、及呼叫處理上下文的掛起(掛斷)檢驗。
圖7是表示由本實施方式的呼叫處理事件引擎30執行的CA(呼叫代理)進程的構造例的說明圖，是對應於依據現有技術的上述圖2的附圖。另外，在現有技術中，核心程序的上層直接就是VoIP應用程式，但在本實施方式的情況下，呼叫事件處理引擎30位於核心程序的上層，VoIP應用程式位於呼叫事件處理引擎30的上層，對應於狀態來適當地生成進程或線程。
由呼叫處理事件引擎30進行的CA(呼叫代理)進程CAP具有1個或多個(圖7中示出4個)數據分組接收部32-1～32-4。各數據分組接收部32-1～32-4在接收到信號時，向核心程序21傳遞該呼叫控制信號，在經過核心程序21中TSS調度程序22的排隊控制之後，向各數據分組接收部32-1～32-4提供來自核心程序21的呼叫控制信號。
CA進程CAP在前段保存接收了來自核心程序21的呼叫控制信號的、用於處理1次事件的事件調度程序31-1，在後段保存用於處理呼叫處理服務的事件調度程序31-2。另外，CA進程CAP為了連結這兩個事件調度程序31-1和31-2，而配置了用於使涉及各種呼叫處理服務的各個事件進行排隊的事件隊列管理對象33-1～33-N。事件隊列管理對象33-1～33-N的基本操作是FIFO(First-In First-Out)。
兩個事件調度程序31-1和31-2分別是用圖4-圖6說明的事件調度程序31。
當各數據分組接收部32-1～32-4接收到信號時，排隊到前段的事件調度程序31-1中，並且為了等待再次輸入數據分組而立刻返回處理(1-4)。在輸入了事件後，事件調度程序31-1生成執行事件處理用的線程。利用事件處理線程，執行從隊列中取出事件的事件處理。圖7表示執行生成事件隊列管理對象33-1～33-N並分配事件、將其排到所生成的對象內的隊列中的處理的情況(5-8)。
用於執行後段呼叫處理的事件調度程序31-2生成事件處理線程，並從被分組的各事件隊列管理對象(呼叫處理對象組)33-1～33-N中抽取事件，執行呼叫處理事件。在執行呼叫處理事件時，適當地訪問有狀態區域。
事件調度程序31-2在執行上述事件的抽取等時，使事件隊列管理對象與事件處理線程結合地保持以後的處理順序。
另外，還可按照事件隊列管理對象來生成事件處理線程，但由於會使核心程序20內的運行隊列阻塞，所以結合事件處理來執行線程數的控制。另外，通過進行控制而將所生成的線程數抑制到最小限度，可以在對上層的有狀態區域34的訪問中不發生線程間的衝突地消除由於鎖定而產生的待機時間。
圖8著眼於後段的呼叫處理事件調度程序31-2，在表示其正常序列的情況時省略了核心程序20和前段的呼叫處理事件調度程序31-1的操作。
信號輸入線程(相當於圖7的數據分組接收部)32接收非同步信號，並對呼叫處理對象組33-GA的信號輸入對象進行呼叫(S301)。此時，呼叫處理對象組33-GA的信號輸入對象向呼叫處理事件調度程序31(31-2)請求處理事件用的上下文(S302)。在請求被排隊時，在生成所請求的上下文之前，全部呼叫處理對象組33-GA、33-GB或信號輸入線程32針對其加入者服務，對對應的呼叫處理執行排他控制(S303)。
例如，呼叫處理對象組33-GA是關於某個發送側加入者的呼叫處理對象的組，呼叫處理對象組33-GB是關於該呼叫的收信側加入者的呼叫處理對象的組。
之後，呼叫處理調度程序31(31-2)生成所請求的上下文(S304)，並實施與呼叫處理對象組33-GA相關的呼叫處理(S305)。
在這樣的呼叫處理對象組33-GA的呼叫處理的實施過程中，為了進行掛起檢驗而計測執行時時間的實際時間。圖8中的鋸齒狀曲線被重疊的部分是計測期間。
另外，在這種某個呼叫處理對象組33-GA的呼叫處理的實施過程中，還生成由其它呼叫處理對象組33-GB執行的非同步事件，接收到該通知的呼叫處理對象組33-GB在進行排隊之後，向呼叫處理事件調度程序31請求自身組33-GB用的上下文，在從呼叫處理事件調度程序31返回對該請求的接收響應後，呼叫處理對象組33-GB重新開始與呼叫處理對象組33-GA相關的呼叫處理。在執行過程中的呼叫處理結束後，呼叫處理對象組33-GA將該情況通知給呼叫處理事件調度程序31。圖8中，雖然為了簡化說明而簡單地予以示出，但呼叫處理事件調度程序31在生成了呼叫處理對象組33-GB所請求的上下文後，實施與呼叫處理對象組33-GB相關的呼叫處理(S306)。
在經過了由核心程序21的TSS調度程序22提供的量子Q後，產生中斷，並中斷與呼叫處理對象組33-GB相關的呼叫處理(S307)。
圖9表示對應於圖8的正常序列的異常序列，僅示出了在圖8中的步驟S304中生成了呼叫處理對象組33-GA所請求的上下文之後的流程。
在與呼叫處理對象組33-GA相關的呼叫處理的執行過程中，在發生了基於邏輯矛盾的循環或基於死鎖的程序停止等時(S401)，由呼叫處理事件調度程序31進行的計測時間會越過閾值時間。
掛起檢驗線程50根據在處理過程中的量子Q內是否檢測出異常狀態的不同，利用以下的第1或第2方法來處理這種異常狀態。
第1方法如下所示。呼叫處理事件引擎30中的掛起檢驗線程50監視對各種執行事件的執行時間(S402)，檢測與呼叫處理對象組33-GA相關的呼叫處理事件的執行時間由於上述原因等超過閾值時間而發生了超時(S403)。此時，掛起檢驗線程50生成新的呼叫處理事件調度程序31NEW(S404)。呼叫處理事件調度程序31NEW例如生成與呼叫處理對象組33-GB相關的上下文(S404)，並在生成與呼叫處理對象組33-GB相關的上下文之後實施呼叫處理(S405、S406)。通過生成以上的新的呼叫處理事件調度程序31NEW，發現由呼叫處理事件調度程序進行的處理得以繼續。即便在根據這種呼叫處理事件調度程序31NEW的呼叫處理的執行過程中，如果經過了由核心程序21的TSS調度程序22提供的量子Q，也會產生中斷，並中斷與呼叫處理對象組33-GB相關的呼叫處理(S407)。
第2方法如下所示。在掛起檢驗線程50的執行時間的監視定時之前，若經過了由核心程序21的TSS調度程序22提供的量子Q，則產生中斷(S410)，並中斷處理。
之後，當由核心程序21的TSS調度程序22提供的量子Q再次成為與所中斷的處理相關的情況而恢復(重新開始)處理時，掛起檢驗線程50進行上下文的繼續判定(S411)。這裡，若判定為阻塞狀態，則將該情況通知給呼叫處理事件調度程序311，削除在步驟S304中產生的上下文(S412)。在判斷為可以生成阻塞狀態等的線程時，執行這種上下文的削除。
根據本實施方式的呼叫處理事件引擎30，除適用採用圖4-圖6說明的呼叫處理事件調度程序31的效果之外，可不依賴於服務方式地容易實現將在呼叫代理(電話交換系統)等必需保持有狀態區域的系統中作為課題的上下文衝突抑制到最小限度。另外，可將系統整體中生成的線程的數量抑制到最小限度，向數據分組接收部等實施短處理的線程頻繁地提供執行契機，實現交互性的提高。
(B)其它實施方式本發明的多重呼叫處理任務處理裝置和方法的適用對象不限於上述實施方式的呼叫代理，也可適用於媒體網關控制器(MGC)等其它電話交換裝置。
權利要求
1.一種由單個CPU依據在存儲器上展開的呼叫處理程序來執行阻塞發生的呼叫處理事件的多重呼叫處理線程處理方法，其特徵在於在安裝有TSS調度程序的OS與呼叫處理應用程式之間，插入呼叫處理事件調度程序，並且上述呼叫處理事件調度程序在上述TSS調度程序管理的CPU執行時間內，裝入並執行1個或多個呼叫處理事件的處理。
2.一種由單個CPU依據在存儲器上展開的呼叫處理程序來執行阻塞發生的呼叫處理事件的多重呼叫處理線程處理方法，其特徵在於在安裝有TSS調度程序的OS與呼叫處理應用程式之間，設置呼叫處理事件引擎，該呼叫處理事件引擎執行上下文的連結/管理、順序控制、呼叫處理上下文的掛起檢驗，上述呼叫處理事件引擎具有呼叫處理事件調度程序，該呼叫處理事件調度程序在上述TSS調度程序管理的CPU執行時間內，裝入並執行1個或多個呼叫處理事件的處理。
全文摘要
提供一種不依賴於OS的TSS調度程序的安裝、最大限度使用CPU、並可執行對呼叫處理事件的處理的多重呼叫處理任務處理方法。本發明涉及一種多重呼叫處理線程(thread)處理方法，CPU根據在存儲器上展開的呼叫處理程序，執行阻塞產生的呼叫處理事件。另外，其特徵在於在安裝TSS調度程序(scheduler)的OS與呼叫處理應用程式之間，設置執行上下文的連結/管理、順序控制、與呼叫處理上下文的調度之呼叫處理事件引擎，該呼叫處理事件引擎具有呼叫處理事件調度程序，在TSS調度程序管理的CPU執行時間內，裝入執行1個或多個呼叫處理事件的處理。
文檔編號H04L29/02GK1797349SQ20051013810
公開日2006年7月5日 申請日期2005年12月28日 優先權日2004年12月28日
發明者小池友嶽, 安藤智和 申請人:衝電氣工業株式會社