專利名稱：多重呼叫處理線程處理方法
技術領域：
本發(fā)明涉及一種多重呼叫處理線程處理方法，適用于例如VoIP服務器，該VoIP服務器適用搭載了TSS(時間分配系統(tǒng))調度程序的通用多任務OS。
背景技術：
就處理大量VoIP信號的VoIP服務器而言，VoIP軟開關是適用的。在適用該VoIP軟開關的、VoIP信號從多個用戶同時到達的系統(tǒng)中，使用Linux(UNIX；注冊商標)、Windows(注冊商標)等通用多任務OS，即便在單一處理器環(huán)境下，在具有多個進程(用戶的呼叫處理請求)的情況下，通過分割并分配CPU使用時間，采用看上去就如同同時處理一樣的TSS調度程序。關于TSS調度程序，在各種文獻中(例如參照非專利文獻1)有所記載。
另外，現(xiàn)有的硬件或操作系統(tǒng)最適于在執(zhí)行基于該TSS調度程序的計算時高速地進行操作。
非專利文獻1澤田勉、澤田綾子、永井正武共著，《理解Linux與Windows用的OS入門》，共立出版株式會社2003年11月發(fā)行，126-130頁發(fā)明內容本發(fā)明所要解決的問題TSS調度程序向進程分配量子(規(guī)定時間)而執(zhí)行。通常，量子的值為8-10m秒左右。在該時間單位下，從CPU的處理中卸下處理過程中的進程，將CPU轉向其它進程。此時，與處理過程中的進程相關的CPU高速緩沖存儲器被刷新(フラッシュ)，并再次構筑與其它進程相關的高速緩沖存儲器。
但是，一般的呼叫控制信號分別由非常短的數(shù)據(jù)分組構成，為了處理各自的事件而使用的時間是比量子短得多的時間，在如此短的時間內，完成了處理。為此，可通過OS的調整等將量子設定為很短，但由于基于調度的CPU高速緩沖存儲器刷新多次發(fā)生，從而CPU的性能明顯降低。
并且，在實現(xiàn)有狀態(tài)(ステ一トフル)的VoIP呼叫控制的情況下，各事件具有關聯(lián)性，事件處理在各狀態(tài)下被左右。利用圖2來說明在一般的多線程環(huán)境下實現(xiàn)此時的處理流程的呼叫控制應用程序(VoIP呼叫控制進程)的實例。
若輸入了呼叫信號(數(shù)據(jù)分組)，則在基于核心程序(的調度程序)內的排隊的等待時間之后，從各輸入部(分組接收部)生成呼叫處理事件隊列對象，并對事件進行排隊(<1>、<2>、<3>)。向每個呼叫處理事件隊列分配線程，利用事件驅動來生成線程或分配事先已生成的線程。該事件隊列成為針對每個呼叫組而生成的對象，在輸入指向已有對象的事件的情況下，僅使指向該對象排隊(<4>)。在此利用事件驅動來生成線程的方式中，由于線程被分配給各個事件，所以希望縮短事件處理的響應時間。但是，在呼叫事件處理時間短于系統(tǒng)調度程序的量子的情況下，為了將CPU轉到其它的線程操作，無用的上下文切換成為必要的。還存在系統(tǒng)不能將CPU迅速地轉到其它線程的情況，從而不能充分利用基于CPU的、用戶程序的可執(zhí)行時間。
之后，在各個呼叫對象執(zhí)行呼叫處理的過程中，頻繁地發(fā)生生成(<5>)、變更(<6>)、或閱覽(<7>)作為有狀態(tài)數(shù)據(jù)區(qū)域的呼叫處理的資源的操作。這些操作表示有多個對象對一個有狀態(tài)數(shù)據(jù)進行訪問。此時，為了數(shù)據(jù)的整合性不因線程的再入而被破壞，有必要實現(xiàn)對數(shù)據(jù)的排他控制。這就是在線程同時對同一區(qū)域進行訪問的情況下，僅使唯一的線程操作，而使其它的線程停止操作。最簡單的是，為了高速地實現(xiàn)排他控制，存在功能提供有幾乎全部OS的Mutex(互斥鎖定)等排他基本單元(primitive)，但使用該排他基本單元的排他控制在CPU被轉到其它線程之前，依賴于由核心程序內的調度程序進行的分配器處理，結果，導致通過量大幅度下降。
另外，通過按事件驅動而生成多個線程，能夠由系統(tǒng)的TSS調度程序來提高服務交互性，但另一方面，不能預測各呼叫事件執(zhí)行契機的發(fā)生時間。
圖3表示與由一般的TSS調度程序執(zhí)行阻塞的事件處理時的執(zhí)行定時相關的時間表實例。為簡單起見，圖3的實例假設一個處理器系統(tǒng)中盡可能沒有事件處理以外的其它處理。
若各事件處理結束，則發(fā)生將CPU轉到其它進程的調度(DP)。另外，為了在量子Q結束后不繼續(xù)處理而強制地產生中斷，并隔著調度發(fā)生了事件處理的切換(圖3中的自事件處理<2>至<3>)。由此，導致了無意的調度。如上所述，在發(fā)生調度時，由于要重新構筑CPU內的高速緩存，而與用戶進程處理的等待時間(latency)(調用)相關。另外，在執(zhí)行針對每個線程的優(yōu)先控制時，當事件處理<2>在處理中途被調度時，其它事件處理<3>被中斷，從而打亂了順序性。
因此，希望存在一種使不依賴于OS中TSS調度程序的安裝、最大限度地使用CPU、并執(zhí)行呼叫處理事件的處理成為可能的多重呼叫處理任務處理方法。
解決問題的手段為了解決上述問題，本發(fā)明的第1方面為一種由單個CPU按照在存儲器上展開的呼叫處理程序來執(zhí)行阻塞發(fā)生的呼叫處理事件的多重呼叫處理線程處理方法，其特征在于在安裝有TSS調度程序的OS與呼叫處理應用程序之間，插入呼叫處理事件調度程序，上述呼叫處理事件調度程序在上述TSS調度程序管理的CPU執(zhí)行時間內，裝入并執(zhí)行對1個或多個呼叫處理事件的處理。
另外，本發(fā)明的第2方面為一種由單個CPU按照在存儲器上展開的呼叫處理程序來執(zhí)行阻塞發(fā)生的呼叫處理事件的多重呼叫處理線程處理方法，其特征在于在安裝有TSS調度程序的OS與呼叫處理應用程序之間，設置呼叫處理事件引擎，該呼叫處理事件引擎執(zhí)行上下文的連結/管理、順序控制、呼叫處理上下文的掛起檢驗(ハングチェック)，上述呼叫處理事件引擎具有呼叫處理事件調度程序，該呼叫處理事件調度程序在上述TSS調度程序管理的CPU執(zhí)行時間內，裝入并執(zhí)行對1個或多個呼叫處理事件的處理。
發(fā)明效果依據(jù)本發(fā)明的多重呼叫處理線程處理方法，呼叫處理事件調度程序在TSS調度程序管理的CPU執(zhí)行時間內，裝入并執(zhí)行對一個或多個呼叫處理事件的處理，所以可不依賴于OS中TSS調度程序的安裝、最大限度地使用CPU、并執(zhí)行呼叫處理事件的處理。


圖1是實施方式的多重呼叫處理線程處理方法的執(zhí)行環(huán)境說明圖。
圖2是表示實現(xiàn)有狀態(tài)的VoIP呼叫控制的、現(xiàn)有VoIP呼叫控制進程實例的說明圖。
圖3是表示與由一般的TSS調度程序執(zhí)行阻塞的事件處理時的執(zhí)行定時相關的時間表實例的說明圖。
圖4是表示與執(zhí)行在將實施方式的呼叫處理事件調度程序與TSS調度程序合用時的阻塞的事件處理的情況下的執(zhí)行定時相關的時間表實例的說明圖。
圖5是表示依據(jù)實施方式的用戶執(zhí)行用線程的基本操作流程圖。
圖6是表示依據(jù)實施方式的掛起檢驗線程的操作流程圖。
圖7是表示基于依據(jù)實施方式的呼叫處理事件引擎的CA(呼叫代理)進程的構造實例的說明圖。
圖8是表示依據(jù)實施方式的呼叫處理事件調度程序的正常序列的序列圖。
圖9是表示依據(jù)實施方式的呼叫處理事件調度程序的異常序列的序列圖。
符號說明
1...多重呼叫處理線程處理裝置、10...硬件、20...通用多任務OS、21...核心程序、22...TSS調度程序、30...呼叫處理事件引擎、31...呼叫處理事件調度程序、40...VoIP應用程序具體實施方式
(A)實施方式下面，參照附圖來詳述依據(jù)本發(fā)明的多重呼叫處理任務外理方法的一種實施方式。
安裝了本實施方式的多重呼叫處理任務處理方法的多重呼叫處理任務處理裝置例如適用于處理大量VoIP信號(例如80萬條線路)的呼叫代理(電話交換系統(tǒng)的一種)中，硬件上與一般的呼叫代理一樣。即，具備CPU、存儲器、內置HDD等大容量存儲裝置、鍵盤、鼠標、顯示器、通信接口部等，CPU經系統(tǒng)總線連接于存儲器，并經系統(tǒng)總線和輸入輸出設備，與大容量存儲裝置、鍵盤、鼠標、顯示器、通信接口部等連接。
該多重呼叫處理任務處理裝置例如適用Linux·Windows等通用多任務OS。如上所述，通用多任務OS在核心程序內具有TSS調度程序。
多重呼叫處理任務處理裝置1如圖1所示，除通用多任務OS20中的核心程序21內的TSS調度程序22之外，還包括位于用戶層中的、具有調度程序功能(呼叫處理事件調度程序31)的呼叫處理事件引擎30，從調度程序功能面看，TSS調度程序22經事件引擎30，將基于VoIP應用程序40的線程作為處理對象。換言之，事件調度程序31是在核心程序21的TSS調度程序22上操作的上下文。
圖4表示根據(jù)實施方式的多重呼叫處理任務處理裝置1執(zhí)行呼叫處理事件時的時間表實例，主要示出呼叫處理事件調度程序31的處理圖象。圖4是與依據(jù)現(xiàn)有技術的圖3相對應的附圖。
呼叫處理事件調度程序31連結進行隊列管理并執(zhí)行順序控制的多個處理時間短的事件，使用一次分配的最大CPU時間(TSS調度程序22提供的量子)Q，實施呼叫處理事件的處理。圖4的實例中，僅在事件處理<1>中埋入CPU時間Q，呼叫處理事件調度程序31在該CPU時間Q內，繼續(xù)處理事件處理<2>(的前半部分)。在各事件處理的切換期間(圖4中的‘Ev切換’)，呼叫處理事件調度程序31的控制處理被中斷，但馬上執(zhí)行下一事件處理。由此，由于在各事件處理之間不執(zhí)行對與調度(圖4中的‘DP’)或呼叫控制處理無關的其它進程(圖4中的‘其它處理’)的處理，所以在相同的CPU處理時間Q內可處理更多的事件。另外，調度是由TSS調度程序22產生的。
這里，由于沒有發(fā)生無意的調度，所以可最大限度地活用CPU高速緩存，有助于進一步高速化。另外，依據(jù)本實施方式的圖4與依據(jù)現(xiàn)有技術的圖3針對同樣的事件處理系列的情況，但現(xiàn)有技術中5次的調度次數(shù)在本實施方式中被減少為3次。
下面，說明本實施方式中的呼叫處理事件調度程序31的控制操作。
若向調度程序31輸入一個事件，則排成用于順序控制的隊列。這里，根據(jù)所排的事件個數(shù)來判定事件是否阻塞，在確認發(fā)生阻塞的情況下，將該情況記錄在調度程序31中。
在調度程序31內，最低生成一個監(jiān)視線程，以監(jiān)視事件隊列和正在執(zhí)行事件處理的線程。若事件被輸入并被排隊，則利用該監(jiān)視線程生成用于實施新的事件處理的線程(用戶執(zhí)行用線程)。
圖5表示用戶執(zhí)行用線程的基本操作。用戶執(zhí)行用線程在生成與所輸入的事件相關的上下文之后(S101)，確認有無事件(S102)，若存在事件，則選擇執(zhí)行的用戶(例如后述的呼叫處理對象組)(S103)，在執(zhí)行該用戶的處理后(S104)，返回上述確認有無事件的步驟。在該用戶處理的執(zhí)行過程中，生成適當事件。另外，還執(zhí)行后述的用于掛起檢驗的時間計測等。
重復步驟S102-S104構成的循環(huán)，當存在經過了TSS調度程序22的最大CPU時間Q的調度時，該循環(huán)處理被中斷，并通過TSS調度程序22對自己的調度而重新開始。由此，實現(xiàn)圖4所示的、在最大CPU時間Q內的事件切換。
在判斷出由于上述進行排隊的其它線程而陷入阻塞狀態(tài)的情況下，監(jiān)視線程選擇是生成新的事件處理還是在生成新的監(jiān)視線程后自然地切換到事件處理線程。監(jiān)視線程切換到事件處理線程后原樣操作的理由在于，在阻塞時，難以確保用于生成新的線程的資源，以及難以保證生成可確實地操作的線程。另外，由于監(jiān)視線程一方的線程優(yōu)先級高，所以可更確實地執(zhí)行事件處理，剪取隊列。
由監(jiān)視線程進行的、對事件處理線程的監(jiān)視通過各事件的執(zhí)行時間計測來進行掛起檢驗。事件處理線程在切換各事件處理時向事件調度程序31中記錄時間戳。監(jiān)視線程根據(jù)該時間戳來計算執(zhí)行各事件處理所需的時間，并判定是否在閾值范圍內。在各事件處理內部產生無限循環(huán)等的情況下，經過閾值的對應時間后，再次生成新的事件處理線程。若在單位時間內發(fā)生多次該事件處理線程的再生成，則視為死鎖(デッドロック)，進行進程的重新開始請求。
圖6用流程圖來表示監(jiān)視線程(掛起檢驗線程)的這種操作。監(jiān)視線程(掛起檢驗線程)在生成掛起檢驗用的上下文之后(S201)，判定有無執(zhí)行中用戶(執(zhí)行過程中的事件處理事件)(S202)，若存在執(zhí)行中用戶，則僅在執(zhí)行中用戶的范圍內選擇執(zhí)行中用戶(S203)，并確認沒有時間突發(fā)(タイムバ一スト)(S204)。然后，若有時間突發(fā)的執(zhí)行中用戶，則生成對這樣的用戶的用戶處理執(zhí)行用的上下文(S205)，返回上述步驟S202。
通過導入上述呼叫處理事件調度程序31，可不依賴于OS20中的TSS調度程序22的安裝地最大限度使用CPU和執(zhí)行呼叫處理事件時的處理。
由于控制線程數(shù)以僅生成在所請求的呼叫事件處理中所需的線程數(shù)，即便在TSS調度程序22的環(huán)境下，也可以使產生保持有狀態(tài)數(shù)據(jù)的呼叫事件彼此不發(fā)生上下文沖突地高速進行處理。另外，可將系統(tǒng)內的線程數(shù)抑制到最小限度，抑制發(fā)生由核心程序21的調度程序22進行的不必要的調度處理，結果，可縮短呼叫事件執(zhí)行契機的定時，確保服務交互性。
本實施方式的呼叫處理事件引擎30是呼叫代理(電話交換系統(tǒng))等高速執(zhí)行阻塞產生的呼叫處理事件用的部件，用于執(zhí)行上下文的連結/管理、順序控制、及呼叫處理上下文的掛起(掛斷)檢驗。
圖7是表示由本實施方式的呼叫處理事件引擎30執(zhí)行的CA(呼叫代理)進程的構造例的說明圖，是對應于依據(jù)現(xiàn)有技術的上述圖2的附圖。另外，在現(xiàn)有技術中，核心程序的上層直接就是VoIP應用程序，但在本實施方式的情況下，呼叫事件處理引擎30位于核心程序的上層，VoIP應用程序位于呼叫事件處理引擎30的上層，對應于狀態(tài)來適當?shù)厣蛇M程或線程。
由呼叫處理事件引擎30進行的CA(呼叫代理)進程CAP具有1個或多個(圖7中示出4個)數(shù)據(jù)分組接收部32-1～32-4。各數(shù)據(jù)分組接收部32-1～32-4在接收到信號時，向核心程序21傳遞該呼叫控制信號，在經過核心程序21中TSS調度程序22的排隊控制之后，向各數(shù)據(jù)分組接收部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。
當各數(shù)據(jù)分組接收部32-1～32-4接收到信號時，排隊到前段的事件調度程序31-1中，并且為了等待再次輸入數(shù)據(jù)分組而立刻返回處理(<1>-<4>)。在輸入了事件后，事件調度程序31-1生成執(zhí)行事件處理用的線程。利用事件處理線程，執(zhí)行從隊列中取出事件的事件處理。圖7表示執(zhí)行生成事件隊列管理對象33-1～33-N并分配事件、將其排到所生成的對象內的隊列中的處理的情況(<5>-<8>)。
用于執(zhí)行后段呼叫處理的事件調度程序31-2生成事件處理線程，并從被分組的各事件隊列管理對象(呼叫處理對象組)33-1～33-N中抽取事件，執(zhí)行呼叫處理事件。在執(zhí)行呼叫處理事件時，適當?shù)卦L問有狀態(tài)區(qū)域。
事件調度程序31-2在執(zhí)行上述事件的抽取等時，使事件隊列管理對象與事件處理線程結合地保持以后的處理順序。
另外，還可按照事件隊列管理對象來生成事件處理線程，但由于會使核心程序20內的運行隊列阻塞，所以結合事件處理來執(zhí)行線程數(shù)的控制。另外，通過進行控制而將所生成的線程數(shù)抑制到最小限度，可以在對上層的有狀態(tài)區(qū)域34的訪問中不發(fā)生線程間的沖突地消除由于鎖定而產生的待機時間。
圖8著眼于后段的呼叫處理事件調度程序31-2，在表示其正常序列的情況時省略了核心程序20和前段的呼叫處理事件調度程序31-1的操作。
信號輸入線程(相當于圖7的數(shù)據(jù)分組接收部)32接收非同步信號，并對呼叫處理對象組33-GA的信號輸入對象進行呼叫(S301)。此時，呼叫處理對象組33-GA的信號輸入對象向呼叫處理事件調度程序31(31-2)請求處理事件用的上下文(S302)。在請求被排隊時，在生成所請求的上下文之前，全部呼叫處理對象組33-GA、33-GB或信號輸入線程32針對其加入者服務，對對應的呼叫處理執(zhí)行排他控制(S303)。
例如，呼叫處理對象組33-GA是關于某個發(fā)送側加入者的呼叫處理對象的組，呼叫處理對象組33-GB是關于該呼叫的收信側加入者的呼叫處理對象的組。
之后，呼叫處理調度程序31(31-2)生成所請求的上下文(S304)，并實施與呼叫處理對象組33-GA相關的呼叫處理(S305)。
在這樣的呼叫處理對象組33-GA的呼叫處理的實施過程中，為了進行掛起檢驗而計測執(zhí)行時時間的實際時間。圖8中的鋸齒狀曲線被重疊的部分是計測期間。
另外，在這種某個呼叫處理對象組33-GA的呼叫處理的實施過程中，還生成由其它呼叫處理對象組33-GB執(zhí)行的非同步事件，接收到該通知的呼叫處理對象組33-GB在進行排隊之后，向呼叫處理事件調度程序31請求自身組33-GB用的上下文，在從呼叫處理事件調度程序31返回對該請求的接收響應后，呼叫處理對象組33-GB重新開始與呼叫處理對象組33-GA相關的呼叫處理。在執(zhí)行過程中的呼叫處理結束后，呼叫處理對象組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相關的呼叫處理的執(zhí)行過程中，在發(fā)生了基于邏輯矛盾的循環(huán)或基于死鎖的程序停止等時(S401)，由呼叫處理事件調度程序31進行的計測時間會越過閾值時間。
掛起檢驗線程50根據(jù)在處理過程中的量子Q內是否檢測出異常狀態(tài)的不同，利用以下的第1或第2方法來處理這種異常狀態(tài)。
第1方法如下所示。呼叫處理事件引擎30中的掛起檢驗線程50監(jiān)視對各種執(zhí)行事件的執(zhí)行時間(S402)，檢測與呼叫處理對象組33-GA相關的呼叫處理事件的執(zhí)行時間由于上述原因等超過閾值時間而發(fā)生了超時(S403)。此時，掛起檢驗線程50生成新的呼叫處理事件調度程序31NEW(S404)。呼叫處理事件調度程序31NEW例如生成與呼叫處理對象組33-GB相關的上下文(S404)，并在生成與呼叫處理對象組33-GB相關的上下文之后實施呼叫處理(S405、S406)。通過生成以上的新的呼叫處理事件調度程序31NEW，發(fā)現(xiàn)由呼叫處理事件調度程序進行的處理得以繼續(xù)。即便在根據(jù)這種呼叫處理事件調度程序31NEW的呼叫處理的執(zhí)行過程中，如果經過了由核心程序21的TSS調度程序22提供的量子Q，也會產生中斷，并中斷與呼叫處理對象組33-GB相關的呼叫處理(S407)。
第2方法如下所示。在掛起檢驗線程50的執(zhí)行時間的監(jiān)視定時之前，若經過了由核心程序21的TSS調度程序22提供的量子Q，則產生中斷(S410)，并中斷處理。
之后，當由核心程序21的TSS調度程序22提供的量子Q再次成為與所中斷的處理相關的情況而恢復(重新開始)處理時，掛起檢驗線程50進行上下文的繼續(xù)判定(S411)。這里，若判定為阻塞狀態(tài)，則將該情況通知給呼叫處理事件調度程序311，削除在步驟S304中產生的上下文(S412)。在判斷為可以生成阻塞狀態(tài)等的線程時，執(zhí)行這種上下文的削除。
根據(jù)本實施方式的呼叫處理事件引擎30，除適用采用圖4-圖6說明的呼叫處理事件調度程序31的效果之外，可不依賴于服務方式地容易實現(xiàn)將在呼叫代理(電話交換系統(tǒng))等必需保持有狀態(tài)區(qū)域的系統(tǒng)中作為課題的上下文沖突抑制到最小限度。另外，可將系統(tǒng)整體中生成的線程的數(shù)量抑制到最小限度，向數(shù)據(jù)分組接收部等實施短處理的線程頻繁地提供執(zhí)行契機，實現(xiàn)交互性的提高。
(B)其它實施方式本發(fā)明的多重呼叫處理任務處理裝置和方法的適用對象不限于上述實施方式的呼叫代理，也可適用于媒體網關控制器(MGC)等其它電話交換裝置。
權利要求
1.一種由單個CPU依據(jù)在存儲器上展開的呼叫處理程序來執(zhí)行阻塞發(fā)生的呼叫處理事件的多重呼叫處理線程處理方法，其特征在于在安裝有TSS調度程序的OS與呼叫處理應用程序之間，插入呼叫處理事件調度程序，并且上述呼叫處理事件調度程序在上述TSS調度程序管理的CPU執(zhí)行時間內，裝入并執(zhí)行1個或多個呼叫處理事件的處理。
2.一種由單個CPU依據(jù)在存儲器上展開的呼叫處理程序來執(zhí)行阻塞發(fā)生的呼叫處理事件的多重呼叫處理線程處理方法，其特征在于在安裝有TSS調度程序的OS與呼叫處理應用程序之間，設置呼叫處理事件引擎，該呼叫處理事件引擎執(zhí)行上下文的連結/管理、順序控制、呼叫處理上下文的掛起檢驗，上述呼叫處理事件引擎具有呼叫處理事件調度程序，該呼叫處理事件調度程序在上述TSS調度程序管理的CPU執(zhí)行時間內，裝入并執(zhí)行1個或多個呼叫處理事件的處理。
全文摘要
提供一種不依賴于OS的TSS調度程序的安裝、最大限度使用CPU、并可執(zhí)行對呼叫處理事件的處理的多重呼叫處理任務處理方法。本發(fā)明涉及一種多重呼叫處理線程(thread)處理方法，CPU根據(jù)在存儲器上展開的呼叫處理程序，執(zhí)行阻塞產生的呼叫處理事件。另外，其特征在于在安裝TSS調度程序(scheduler)的OS與呼叫處理應用程序之間，設置執(zhí)行上下文的連結/管理、順序控制、與呼叫處理上下文的調度之呼叫處理事件引擎，該呼叫處理事件引擎具有呼叫處理事件調度程序，在TSS調度程序管理的CPU執(zhí)行時間內，裝入執(zhí)行1個或多個呼叫處理事件的處理。
文檔編號H04L29/02GK1797349SQ20051013810
公開日2006年7月5日 申請日期2005年12月28日 優(yōu)先權日2004年12月28日
發(fā)明者小池友岳, 安藤智和 申請人:沖電氣工業(yè)株式會社