專利名稱：資源管理方法、資源管理設備、資源管理程序及存儲介質的制作方法
技術領域：
本發(fā)明涉及用于管理針對電子設備的硬件資源分配的資源管理方法、資源管理設備、資源管理程序及存儲介質。
背景技術：
存在若干方法用于避免來自多個執(zhí)行任務的使用硬件資源(下文簡稱為資源)的請求的沖突。舉例說明，一個方法(下文稱為第一方法)涉及按照預定優(yōu)先級來限制使用資源的權利。另一方法(第二方法)是所謂的單任務方法，其在任何時間將可執(zhí)行應用程序的數(shù)量限制為單個任務。又一方法(第三方法)涉及在任何時間僅允許已經獲得資源的第一應用程序利用那些資源。再一方法(第四方法)涉及通過軟件來實施一層，在該層中硬件資源通過抽象的實體來代表，從而這些資源可以虛擬方式被同時訪問。
日本專利待審公開Hei 9-16416(圖1)公開了用于分配硬件資源的技術。所公開的技術涉及根據(jù)請求的擁擠程度在多任務處理環(huán)境中調整資源處理請求的等待時間，使得這些資源可被擇優(yōu)分配。換而言之，根據(jù)其擁擠程度為較低優(yōu)先級的處理請求進行不同的延遲，使得資源被擇優(yōu)地分配給較高優(yōu)先級的請求。
然而，上面的第一和第二方法具有對應用程序的執(zhí)行施加限制的缺陷；涉及較少操作限制的方法是優(yōu)選的。第三方法要求資源請求在系統(tǒng)內具有同一優(yōu)先級；優(yōu)先級方面可能存在的任何差異均被忽略。如果想要通過第三方法按照優(yōu)先級來分配資源，則有必要由使用者負責進行優(yōu)先級管理。對于第四方法，高性能的環(huán)境比如個人計算機是強制性的；所涉及的方案對于具有有限功能和性能的設備比如移動電話來說是難以負擔的。

發(fā)明內容
本發(fā)明是考慮到上述情況而做出的，提供了資源管理方法、資源管理設備、資源管理程序及存儲介質，用于有效率和靈活地管理硬件資源在多個應用程序之間的分配，以便實施獨占、無沖突的資源使用。
按照本發(fā)明的一個實施例，提供了一種資源管理方法，包括步驟從所述多個處理裝置的任一個接受資源獲取請求；確定與來自所述一個處理裝置的所述資源獲取請求相應的資源是否與將由另一處理裝置使用的資源沖突；決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；當從未被給予使用所述資源的許可的處理裝置接收有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；當從已被給予使用所述資源的許可的處理裝置接收說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及將說明所述資源已被獲取的獲取完成通知發(fā)出到在所述列表檢查步驟中從所述列表檢查出的所述釋放通知請求處理裝置。
在上述實施例的一個優(yōu)選變形中，可以逐個功能地接受資源獲取請求，確定資源之間沖突的存在，決定是否給予使用資源的許可，將這些資源在列表中編目，檢查該列表，以及發(fā)出獲取完成通知，功能代表進行所需處理而需要的至少一個資源。
按照本發(fā)明，盡管是處理裝置最終獲取資源，但是資源管理設備對于如何確定資源之間沖突的存在、如何決定是否給予使用資源的許可、以及如何分配使用資源的權利實行管理。無法獲取給定資源的處理裝置可請求在所涉及的資源被釋放時立即得到通知。如果以前正使用該資源的處理裝置已經釋放它，并且有任何處理裝置請求得到有關所涉及的資源的釋放的通知，則資源管理設備將向請求處理裝置發(fā)出說明該資源已被釋放的獲取完成通知。
也就是，本發(fā)明的資源管理設備對于如何確定資源之間沖突的存在、如何決定是否給予使用資源的許可、以及如何分配使用資源的權利實行管理。如果以前正使用該資源的任何處理裝置已經釋放它，并且有另一處理裝置請求得到有關該資源的釋放的通知，則資源管理設備向請求處理裝置發(fā)出說明該資源已被釋放的獲取完成通知。這使得能在多個處理裝置之間(例如應用程序)有效率和靈活地分配資源，由此實施獨占、無沖突的資源使用。


圖1是示出了功能與資源之間對應關系的列表圖；圖2是概括了作為本發(fā)明實施例的進行資源管理的電子設備結構的方框圖；圖3是概括了作為體現(xiàn)本發(fā)明的電子設備實例的移動電話終端結構的方框圖；圖4是時序流程圖，其示出了資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上高于應用程序APP2，資源管理器未接收通知釋放資源的請求；圖5是時序流程圖，其示出了資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上高于應用程序APP2，資源管理器接收通知釋放資源的請求；圖6是時序流程圖，其示出了資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上等于或低于應用程序APP2，資源管理器未接收通知釋放資源的請求；圖7是時序流程圖，其示出了資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上等于或低于應用程序APP2，資源管理器接收通知釋放資源的請求；以及圖8時序流程圖，其示出了資源管理器如何管理在應用程序APP1、應用程序APP2與應用程序APP3之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上等于或低于應用程序APP2，應用程序APP2又在優(yōu)先級上低于應用程序APP3，資源管理器接收通知釋放資源的請求。
具體實施例方式
現(xiàn)在參照附圖，將描述本發(fā)明的優(yōu)選實施例。
在討論實施例的具體結構之前，下面將概括本發(fā)明提出的資源管理方案。
按照本發(fā)明，硬件資源(簡稱為資源)是以稱為功能的單位來管理的。功能代表一個或多個資源，它們被用來進行對應于本發(fā)明的處理裝置的應用程序所需的處理。同樣地，功能是資源管理的最小增量。具體功能可包括壓縮運動圖像再現(xiàn)功能和數(shù)字相機功能，它們代表了電子設備的相應能力。具體而言，壓縮運動圖像再現(xiàn)功能被安排為代表用于再現(xiàn)壓縮運動圖像所必需的若干資源。這樣的資源可包括數(shù)據(jù)獲取資源，用于從存儲器或通過通信線路獲取壓縮運動圖像數(shù)據(jù)；數(shù)據(jù)擴展資源，比如用于擴展已壓縮的移動畫面數(shù)據(jù)的電路；顯示資源，比如用于在其數(shù)據(jù)擴展之后顯示運動圖像的顯示設備；以及音頻輸出資源，比如用于輸出由擴展的數(shù)據(jù)導出的聲音的揚聲器。類似地，數(shù)字相機功能被設置為代表數(shù)字化捕獲圖像所需要的資源。這些資源可包括數(shù)字相機模塊，用于捕獲圖像；數(shù)據(jù)壓縮資源，比如用于壓縮所捕獲的圖像數(shù)據(jù)的電路；以及記錄資源，比如用于將壓縮的圖像數(shù)據(jù)記錄到存儲器的電路。與每個都代表資源的上述功能相結合地處理的數(shù)據(jù)例如是32位長的位圖信息。
圖1是示出了在功能與資源之間對應關系的列表圖。該圖描繪了功能與資源之間的一般化關系。圖1的左手側列(垂直軸)中的參考字符FA至FN分別標示不同的功能；頂行(水平軸)中的參考字符RA至RO分別代表不同的資源。在圖1中，該列中的每個功能被示出為包括由指向頂行的空心圓指定的資源。具體而言，圖1中的功能FA至FD被示出為與用于其使用的資源RC相關聯(lián)，功能FE和FF則與資源FB相關聯(lián)。類似地，功能FG被示出為與用于其使用的資源RH相關聯(lián)，功能FH與資源RI相關聯(lián)，功能FI與資源RE、RG、RI、RJ和RL相關聯(lián)；功能FJ與資源RA、RC、RD和RE相關聯(lián)；以及功能FK與資源RF、RG、RI至RL和RN相關聯(lián)。功能FL至FN的說明被省略。
圖2是概括了作為本發(fā)明實施例、進行資源管理的電子設備的結構的方框圖。本發(fā)明的電子設備包括資源管理器1、應用程序4、資源(硬件資源)6和資源訪問庫5。資源管理器1實現(xiàn)按照本發(fā)明的資源管理設備的功能。應用程序4構成了被該電子設備用于進行各種處理的軟件。資源6由并入該電子設備中的各種硬件資源組成。資源訪問庫5用作為允許應用程序4獲得對資源6的訪問的接口。
資源管理器1是按照本發(fā)明來執(zhí)行資源管理的主要模塊，對可由應用程序4訪問的資源6提供獨占控制。資源管理器1具有資源管理器處理模塊2和資源管理器訪問庫3。資源管理器訪問庫3起到本發(fā)明的接受裝置和通知發(fā)出裝置的作用。庫3由此用作為允許應用程序4訪問資源管理器處理模塊2的接口。利用資源管理器訪問庫3，應用程序4可向資源管理器處理模塊2請求使用資源的權利，或者可向后者通知釋放的資源。資源管理器處理模塊2起到本發(fā)明的沖突確定裝置、決定裝置、列表編目裝置和列表檢查裝置的作用。資源管理器處理模塊2具有句柄管理模塊8和資源管理模塊7，用于逐個功能地進行資源管理。句柄管理模塊8管理資源句柄與功能之間的對應關系。句柄管理模塊8具有一列表，其中編號被分配給由應用程序4請求的資源。該列表被用來查明哪些應用程序正在使用哪些資源，以及確定在應用程序之間關于資源使用的沖突。資源管理模塊7逐個功能地管理資源。更具體而言，句柄管理模塊8具有圖1的表格，其定義了功能與資源之間的對應關系。對于資源管理，資源管理模塊7進行檢查以確定哪些資源被鏈接到哪些資源編號，以及哪些資源被哪些功能所代表。資源管理模塊7還給予應用程序使用資源的許可。由于資源管理器1中的資源管理器訪問庫3、句柄管理模塊8和資源管理模塊7以協(xié)同方式來運作，所以這些模塊在下文中將被整體地看作為資源管理器1。
在圖2的結構中，應用程序4每個都能夠請求至少一個功能。通過請求功能，應用程序4請求資源管理器1以獲取將由所涉及的功能使用的資源。如果假定兩個或更多應用程序4通過同時或在不同時間請求功能來請求獲取資源，則資源管理器1參照圖1的對應表來比較功能以確定待使用資源的相符。經過比較，資源管理器1確定是否存在資源沖突。如果資源管理器1確定資源沖突已經出現(xiàn)，則管理器1進行隨后將描述的資源沖突解決處理。如果確定尚無資源沖突出現(xiàn)，則資源管理器1給予每個應用程序4使用其各自資源的許可。
當獲取資源時，應用程序4向資源管理器1通知功能名和所需資源的優(yōu)先級、關于資源獲取的原因、訪問句柄和進程ID。每個應用程序預先與所涉及的應用程序的優(yōu)先級、所涉及的每個功能的優(yōu)先級、以及每個相應資源的優(yōu)先級所構成的優(yōu)先級信息相關聯(lián)。資源管理器1在解決可能出現(xiàn)的任何資源沖突時使用優(yōu)先級信息。如果獲取資源的嘗試失敗，或者如果使用資源的權利被取消，則利用資源獲取原因的資源管理器1向請求所涉及的資源的應用程序4通知獲取它的嘗試為何已失敗，或者使用它的權利為何已取消。訪問句柄構成了用來同時訪問多個功能的信息。進程ID是用來標識請求資源的應用程序4的信息。對于該實施例，只有在由所有指定功能所用的所有資源已被獲取時，資源獲取才認為成功。資源獲取的任何其他情況被認為是失敗。在獲取任何資源的嘗試失敗的情況下，相應功能被釋放，即使某些所請求資源已被獲取。資源管理器1逐個功能地向應用程序4通知資源獲取結果。
不再使用的任何資源應當盡快地被釋放。所涉及的資源由至今仍在使用它的應用程序4來釋放。換而言之，一旦被獲取，則任何資源將僅由在過去已經獲取它的應用程序4來釋放。在釋放資源之后，應用程序4向資源管理器1通知所涉及的資源的釋放。在此發(fā)出的資源釋放完成通知包括在資源的獲取時所用的訪問句柄和進程ID。盡管多個功能可被同時指定，但是釋放完成通知是逐個功能地發(fā)出的，因為該處理是逐個功能地進行的。
應用程序4可發(fā)出資源釋放通知請求，其請求資源管理器1通知由所有被請求的功能所使用的所有資源的釋放?？膳c每個資源釋放通知請求相結合地指定多個功能。當由同時指定的所有功能所使用的所有資源被釋放時，資源管理器1將該釋放通知發(fā)出到已請求得到資源釋放的通知的應用程序4。當發(fā)送該釋放通知請求時，應用程序4向資源管理器1通知請求釋放通知的功能的名字、釋放等待優(yōu)先級、通知等待優(yōu)先級、訪問句柄和進程ID。只有當所有指定功能的所有資源已被釋放時，資源管理器1才發(fā)送釋放通知到應用程序4。如果資源在通知等待時間內未被釋放，則資源管理器1將釋放通知超時通知發(fā)送到應用程序4。資源等待狀態(tài)可由已發(fā)出釋放通知請求的應用程序4取消，該應用程序4通過向資源管理器1通知在資源獲取時所用的訪問句柄和進程ID來實現(xiàn)該取消。也就是，對于任何資源的釋放的等待狀態(tài)僅能由等待資源釋放的應用程序4來取消。
當接收資源釋放通知時，應用程序4應當無延遲地請求所涉及的資源或者向資源管理器1通知不再需要該資源。如果應用程序已請求該資源，則資源管理器1在該資源下一次被釋放時將資源釋放通知發(fā)送到下一通知目的地的應用程序。如果不需要該資源，則資源管理器1將資源釋放通知發(fā)送到下一通知目的地的應用程序。如果應用程序4無法標示它是否需要資源，則資源管理器1在經過預定時段時識別超時，視該資源為不必要。在此情況下，資源管理器1將資源釋放通知發(fā)送到下一通知目的地的應用程序。假定在經過由請求得到資源釋放通知的應用程序所指定的時段時，未從利用所涉及的資源的應用程序接收資源釋放通知。在這樣的情況下，資源管理器1取消等待釋放請求的狀態(tài)，將超時通知發(fā)送到請求得到資源釋放通知的應用程序。如果存在有請求得到資源釋放通知的多個應用程序，則釋放通知首先被提供給比任何其他應用程序具有更高優(yōu)先級的應用程序，以及提供給其發(fā)出通知請求的時間比其他請求者更遲的應用程序。也就是，釋放通知首先被提供給最高優(yōu)先級的應用程序。如果存在具有同一優(yōu)先級的多個應用程序，則該通知被提供給發(fā)出通知請求的時間比任何其他應用程序更遲的應用程序。
多個功能可由資源獲取請求、資源釋放請求或釋放通知請求同時指定。所涉及的處理是以每個功能單獨進行的，結果的通知是逐個功能地發(fā)出的。當多個功能被同時指定時，處理結果因功能而變化。
而且，資源管理器1可對編目的應用程序周期性地進行“健康”檢查。如果作為健康檢查的結果，檢驗出應用程序的缺失，則資源管理器1釋放由所涉及的應用程序所已經使用的所有資源，取消關于該應用程序所編目的內容。
現(xiàn)在將單獨地描述為資源沖突的控制而采取的具體動作。
可能出現(xiàn)這樣的情形，即在應用程序4針對一功能進行請求時，該功能包括由另一應用程序當前使用的資源，使得獲取該功能的請求帶來資源沖突。在此情況下，資源管理器1向比其他應用程序具有更高優(yōu)先級的應用程序提供使用該資源的權利。如果這些應用程序具有同一優(yōu)先級，則資源管理器1將使用該資源的權利提供給最近進行該獲取請求的應用程序。如果使用該資源的權利已被取消，則資源管理器1向利用該資源的應用程序通知為何已造成該取消，等待來自該應用程序的響應。一般在針對導致取消權利的原因的通知而返回響應時，或者在繼發(fā)送原因通知之后發(fā)送資源釋放請求時，取消使用資源的權利。
當應用程序4被設置為同時獲取多個功能時，資源管理器1進行檢查以確定否有任一功能由于資源沖突而無法被獲取。如果發(fā)現(xiàn)有任一功能由于沖突而不可得到，則資源管理器1將獲取失敗的單個通知作為響應提供給應用程序4，以免徒勞地進行資源釋放處理。在此情況下，應用程序4停止獲取所有指定功能的資源。如果這些功能的獲取不受制于任何資源沖突，則資源管理器1確定是否為每個指定功能獲取了資源。每個功能的資源獲取結果被報告給應用程序4。
可能發(fā)生這樣的情形，即在應用程序4正在進行資源釋放通知請求并等待該請求的響應的同時，資源管理器1在響應等待時間結束之前從另一應用程序接收對于同一資源的另一請求。在此情況下，資源管理器1將獲取該資源的許可給予比其他應用程序具有更高優(yōu)先級的應用程序，或者發(fā)出請求的時間比其他應用程序更遲的應用程序。
還可能發(fā)生這樣的情形，即對于有關取消該獲取資源的權利的原因的通知的響應，或者對于釋放資源的請求，在“釋放處理時間”內不被報告，該釋放處理時間是由應用程序4在請求獲取所涉及的資源時指定的。在這樣的情況下，資源管理器1將“釋放錯誤”通知發(fā)送到已經進行該獲取請求的應用程序以及利用所涉及的資源的應用程序。在釋放錯誤的情況下，資源管理器1將所有后續(xù)的獲取請求視為釋放錯誤，除非和直到所涉及的資源被釋放。
現(xiàn)在將說明圖2中所示的模塊之間傳送的數(shù)據(jù)。
應用程序4向資源管理器訪問庫3發(fā)送如下數(shù)據(jù)初始設置請求數(shù)據(jù)、停止設置請求數(shù)據(jù)、用于內-外同步的資源獲取請求數(shù)據(jù)、資源釋放請求數(shù)據(jù)、資源釋放通知請求數(shù)據(jù)和資源釋放通知請求取消數(shù)據(jù)。初始設置請求數(shù)據(jù)由標示消息接收方法的數(shù)據(jù)和接收目的地指針組成。資源獲取請求數(shù)據(jù)由功能組數(shù)據(jù)、優(yōu)先級數(shù)據(jù)、獲取原因數(shù)據(jù)、資源釋放最大處理時間數(shù)據(jù)和資源句柄組成，功能組數(shù)據(jù)由功能名構成。資源釋放請求數(shù)據(jù)由資源句柄形成。資源釋放通知請求數(shù)據(jù)由功能組數(shù)據(jù)、優(yōu)先級數(shù)據(jù)和資源句柄構成。資源釋放通知請求取消數(shù)據(jù)由資源句柄構成。優(yōu)先級數(shù)據(jù)表示獲取請求和釋放通知請求的優(yōu)先級。獲取原因數(shù)據(jù)表示資源獲取的原因。資源釋放最大處理時間數(shù)據(jù)代表應用程序釋放它正在使用的資源所實際需要的最大時間。
應用程序4將進程ID、消息類型數(shù)據(jù)和消息數(shù)據(jù)發(fā)送到句柄管理模塊8。進程ID特定于所涉及的應用程序。消息類型數(shù)據(jù)包括初始設置請求消息、停止設置請求消息、獲取請求消息、釋放請求消息、釋放通知請求消息和釋放通知取消請求消息。消息數(shù)據(jù)標示與使用中的每個消息類型相對應的消息內容。在消息類型之中，初始設置請求消息是用于對所涉及的應用程序編目的消息。停止設置請求消息是取消應用程序編目的消息。獲取請求消息用來請求獲取功能。釋放請求消息是用于請求釋放功能的消息。釋放通知請求消息用來等待資源釋放。釋放通知取消請求消息是用于取消等待資源釋放的狀態(tài)的消息。初始設置請求消息包含消息接收方法和接收目的地指針。獲取請求消息包含資源句柄、待獲取的功能組、獲取優(yōu)先級、獲取原因、資源釋放最大處理時間、以及響應于該資源獲取而向其發(fā)送第一消息的目的地。釋放請求消息包含待釋放的資源的資源句柄。釋放通知請求消息包含用于釋放通知的資源句柄、等待資源釋放的功能組、釋放通知的優(yōu)先級和釋放通知等待時間。釋放通知取消請求消息包含用于取消釋放通知的資源句柄。
句柄管理模塊8將資源句柄數(shù)據(jù)、消息類型數(shù)據(jù)和原因數(shù)據(jù)發(fā)送到應用程序4。原因數(shù)據(jù)代表失敗請求的原因，以及產生請求以釋放一釋放請求通知的原因。消息類型數(shù)據(jù)包括成功獲取通知消息、未成功獲取通知消息、釋放請求通知消息、釋放通知消息、釋放通知等待超時通知消息和釋放錯誤通知消息。成功獲取通知消息是標示資源成功獲取的獲取請求批準消息。未成功獲取通知消息是標示獲取資源的嘗試失敗的獲取拒絕消息。釋放請求通知消息是請求實施句柄釋放的消息。釋放通知消息標示所有指定資源已被釋放。釋放通知等待超時通知消息是標示資源在經過釋放通知等待時間后尚未被釋放的消息。釋放錯誤通知消息是通知響應于釋放通知而進行的釋放請求的超時信號的消息。該消息被提供給請求獲取資源的應用程序以及請求釋放資源的應用程序。
句柄管理模塊8將消息ID、消息類型數(shù)據(jù)、功能組數(shù)據(jù)、進程ID、優(yōu)先級數(shù)據(jù)、原因數(shù)據(jù)、資源釋放時間數(shù)據(jù)和釋放等待時間數(shù)據(jù)發(fā)送到資源管理模塊7。消息ID是標識每個消息的標識符。當存在響應于發(fā)送的消息而返回的消息時，響應消息的消息ID變成所發(fā)送的消息的標識符。消息類型數(shù)據(jù)包括獲取請求消息、釋放請求消息、不需要響應消息、釋放通知請求消息和原因響應消息。功能組數(shù)據(jù)標示功能組。進程ID是標識應用程序進程的標識符。優(yōu)先級數(shù)據(jù)是標示獲取請求和釋放通知請求的優(yōu)先級的數(shù)據(jù)。原因數(shù)據(jù)標示資源獲取的原因。資源釋放時間數(shù)據(jù)是表示應用程序釋放它正在使用的資源所實際需要的最大時間的數(shù)據(jù)。釋放通知等待時間數(shù)據(jù)是表示從發(fā)出釋放通知請求之時到接收釋放通知為止的超時時間段的數(shù)據(jù)。在消息類型之中，獲取請求消息是請求獲取功能的消息。釋放請求消息是用于請求釋放功能的消息。不需要響應消息被用來響應于標示釋放功能組的所接收通知而通知不需要該功能組。釋放通知請求消息是用于請求得到有關該指定功能的所有資源的釋放的通知的消息。原因響應消息是作為對原因通知的響應而發(fā)出的消息。
資源管理模塊7將消息ID、消息類型數(shù)據(jù)、功能組數(shù)據(jù)、進程ID、原因數(shù)據(jù)、原因進程數(shù)據(jù)和原因優(yōu)先級數(shù)據(jù)發(fā)送到句柄管理模塊8。消息ID是標識每個消息的標識符。同樣地，該消息ID用作由句柄管理模塊8發(fā)送的每個消息的消息ID。消息類型數(shù)據(jù)包括成功獲取通知消息、未成功獲取通知消息、成功釋放通知消息、未成功釋放通知消息、原因通知消息、釋放通知消息、釋放通知超時通知消息和釋放錯誤通知消息。功能組數(shù)據(jù)是表示功能組的數(shù)據(jù)。進程ID是標識應用程序進程的標識符。原因數(shù)據(jù)是代表資源獲取失敗、釋放失敗、原因通知產生、以及在標示相應功能的釋放的通知之前的資源獲取的原因的數(shù)據(jù)。原因進程數(shù)據(jù)是標識這樣的進程的數(shù)據(jù)，該進程造成了資源獲取失敗、釋放失敗或者原因通知的產生；或者是標識這樣的進程的數(shù)據(jù)，該進程造成了在標示相應功能的釋放的通知之前的資源獲取。原因優(yōu)先級數(shù)據(jù)代表這樣的優(yōu)先級，其造成了資源獲取失敗、釋放失敗或者原因通知產生；或者這樣的優(yōu)先級，其造成了在標示相應功能釋放的通知之前的資源獲取。在消息類型中，成功獲取通知消息是標示成功獲取功能的消息。未成功獲取通知消息是標示獲取功能的嘗試失敗的消息。成功釋放通知消息是標示成功釋放功能的消息。未成功釋放通知消息標示釋放功能的嘗試失敗。原因通知消息是這樣的消息，其標示使用功能資源的權利被取消。釋放通知消息標示由釋放通知請求所指定的功能的所有資源已被釋放。釋放通知超時通知消息是標示釋放通知請求的超時的消息。釋放錯誤通知消息標示對起源于獲取請求的原因通知的響應的超時。該消息在兩個方向上發(fā)送一個是通知原因的方向；另一個是請求獲取的方向。
圖3是概括了作為體現(xiàn)本發(fā)明的電子設備實例的移動電話終端的結構的方框圖。在圖3的組件之中，圖2中所示的組件由相似的標號來指定。圖3中出現(xiàn)的組件簡單地構成了移動電話終端的主要結構。
在圖3的實例中，移動電話終端的應用程序4包括電話應用程序43，其實現(xiàn)該移動電話終端的電話功能；時鐘應用程序44，用于實現(xiàn)時鐘功能；屏幕應用程序45，用于實現(xiàn)顯示能力和屏保功能；應用程序啟動器46，用于開始應用程序；以及用戶定義的應用程序(APP1，APP2)41、和42。這些應用程序被連接到應用程序框架14，即應用程序的基礎。應用程序框架14繼而連接到窗口管理器13。窗口管理器13經由圖2中所示的資源訪問庫5連接到操作系統(tǒng)(OS)21。
在圖3的實例中，資源6包括液晶顯示器(LCD)設備62，示例性地用于提供顯示；驅動程序61，用于驅動設備62；按鍵設備64，其一般是十鍵的小鍵盤；驅動程序63，用于驅動按鍵設備64；系統(tǒng)設備66，其支持移動電話終端的發(fā)送和接收(通信)能力以及其他主要功能；驅動程序65，用于驅動系統(tǒng)設備66；相機設備68，其用作為數(shù)字相機；驅動程序67，用于驅動相機設備68；存儲器設備(存儲器/快擦寫存儲器堆(Mem/Flash FILE))72，其是用作為本發(fā)明的存儲介質的存儲器；驅動程序(存儲器/文件系統(tǒng)任務(Mem/FileSys TASK))71，用于寫文件到存儲器設備72和從其讀文件；雜項硬件70，比如LED(發(fā)光二極管)和音頻設備；以及雜項驅動程序69，用于驅動硬件70。CPU(中央處理單元)23控制這些設備以及與設備相結合執(zhí)行各種操作。
圖3中的任務管理器11在應用程序4的執(zhí)行期間管理任務。事件管理器12管理各種事件。資源管理器(ResMan)1對應于圖2中所示的資源管理器1。
現(xiàn)在將參照圖4至8的時序流程圖來描述上述實施例的資源管理器一般如何管理資源。
圖4是流程圖，其示出了本發(fā)明的資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上高于應用程序APP2(APP1＞APP2)，而應用程序APP1比應用程序APP2更早地發(fā)出指定功能的資源獲取請求。在圖4的實例中，應用程序APP2未發(fā)出釋放通知請求。
參照圖4，資源管理器示例性地在步驟S1中從應用程序APP1接收指定有功能的新資源獲取請求。在步驟S2中，資源管理器確定是否有資源沖突。由于將由指定的功能所使用的資源當前未被任何其他應用程序使用，所以資源管理器在步驟S3中將獲取資源的許可返回給應用程序APP1。在步驟S4中，應用程序APP1獲取所需資源。
隨后在步驟S5中，資源管理器從應用程序APP2接收新的資源獲取請求，其指定了包括正在使用的同一資源的功能。在此情況下，資源管理器在步驟S6中檢查確定是否有資源沖突。由于應用程序APP2將需要使用的資源正在被應用程序APP1使用，所以資源管理器在步驟S7中將未成功獲取通知返回給應用程序APP2。在步驟S8中，繼獲取所需資源的嘗試失敗之后，應用程序APP2進行獲取拒絕處理。
圖5是時序流程圖，其示出了本發(fā)明的資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突，應用程序APP1在優(yōu)先級上高于應用程序APP2(APP1＞APP2)，而應用程序APP1比應用程序APP2更早地進行指定功能的資源獲取請求。在圖5的實例中，與圖4的實例相對，應用程序APP2發(fā)出釋放通知請求。圖5中與參照圖4已經討論的步驟等效的步驟將不再被進一步描述。
在圖5的步驟S8中，應用程序APP2進行該拒絕獲取處理，將釋放通知請求發(fā)送到資源管理器。此時，與請求應用程序相關聯(lián)地，資源管理器在列表中對由釋放通知請求所指定的功能進行編目。隨后，應用程序APP1在步驟S10完成其處理和釋放資源。在步驟S11中，資源管理器從應用程序APP1接收釋放完成通知。在步驟S12中，資源管理器搜尋來自任何其他應用程序的任何釋放通知請求。在此情況下，來自應用程序APP2的釋放通知請求已經在列表中被編目。于是資源管理器在步驟S13中向應用程序APP2通知所涉及的資源已被釋放。
當這樣被通知所需資源的釋放時，應用程序APP2進行到步驟S14，發(fā)出另一指定該功能的獲取請求。在于步驟S14中接收該獲取請求之后，資源管理器在步驟S15中確定是否有資源沖突。由于將由所指定的功能使用的資源當前未被任何其他應用程序使用，所以資源管理器在步驟S16中將獲取完成通知返回到應用程序APP2。在步驟S17中，應用程序APP1獲取所需資源。
圖6是另一時序流程圖，其示出了本發(fā)明的資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突。在此情況下，盡管應用程序APP1也比應用程序APP2更早地進行指定功能的資源獲取請求，但是應用程序APP1的優(yōu)先級等于應用程序APP2，使得比其他應用程序更晚地進行獲取請求的應用程序被提供給更高優(yōu)先級(APP1≤APP2)。在圖6的實例中，應用程序APP1并未發(fā)出釋放通知請求。圖6中與參照圖4和5已經討論的步驟等效的步驟將不再被進一步討論。
在圖6的步驟S6中，資源管理器在確定資源沖突的存在時發(fā)現(xiàn)應用程序APP2的優(yōu)先級等于應用程序APP1，應用程序APP1比其他應用程序更晚地進行資源獲取請求。在此情況下，資源管理器在步驟S21中將資源釋放請求發(fā)出到應用程序APP1。在接收該釋放請求時，應用程序APP1在步驟S22和S23中進行資源釋放處理。在步驟S24中，應用程序APP1將釋放完成通知發(fā)送到資源管理器。
當從應用程序APP1收到釋放完成通知時，資源管理器在步驟S25中將獲取完成通知發(fā)送到應用程序APP2。在步驟S26中，應用程序APP2獲取所需資源。
在完成其處理之后，應用程序APP2在步驟S27中釋放資源。在步驟S28中，資源管理器從應用程序APP2接收釋放完成通知。在步驟S29中，資源管理器在列表中對釋放的資源進行編目。
圖7是另一時序流程圖，其示出了本發(fā)明的資源管理器如何管理在應用程序APP1與APP2之間關于資源使用的沖突。在此情況下，盡管應用程序APP1也比應用程序APP2更早地進行指定有功能的資源獲取請求，但是應用程序APP1的優(yōu)先級等于應用程序APP2，使得比其他應用程序更晚地進行獲取請求的應用程序被提供給更高優(yōu)先級(APP1≤APP2)。在圖7的實例中，與圖6的實例相對，應用程序APP1發(fā)出釋放通知請求。圖7中與參照圖4，5和6已經討論的步驟等效的步驟將不再被進一步描述。
在圖7的步驟S23中，應用程序APP1釋放它已經使用的資源。在步驟S30中，應用程序APP將釋放完成通知和釋放通知請求發(fā)送到資源管理器。
之后在步驟S28中，資源管理器從應用程序APP2接收釋放完成通知。在步驟S31中，資源管理器檢驗列表中所含內容，在該列表中應用程序被編目為等待資源釋放。從該釋放等待列表中，資源管理器發(fā)現(xiàn)應用程序APP1已經發(fā)出釋放通知請求。于是資源管理器在步驟S32將資源釋放通知發(fā)送到應用程序APP1。
在從資源管理器接收該資源釋放通知之后，應用程序APP1在步驟S33中為了另一次的資源獲取嘗試而準備在列表中再次進行編目。在準備完成時，應用程序APP1在步驟S34中將獲取請求發(fā)送到資源管理器。
在步驟S35中，資源管理器確定是否有資源沖突。當此時未檢測到沖突時，資源管理器在步驟S36中將獲取完成通知返回到應用程序APP1。在步驟S37中，應用程序APP1再次獲取所需資源。
圖8是時序流程圖，其示出了本發(fā)明的資源管理器如何管理在應用程序APP1、應用程序APP2和應用程序APP3之間關于資源使用的沖突。具體而言，圖8的實例假設了應用程序APP1最初進行資源獲取請求，繼而是應用程序APP2和APP3，它們均以此次序進行同一請求。還假設應用程序APP3比應用程序APP1或APP2具有更高優(yōu)先級，后兩者在優(yōu)先級上等同。應用程序發(fā)出請求越遲，該應用程序的優(yōu)先級越高(APP1≤APP2＜APP3)。在圖8的實例中，應用程序APP1發(fā)出釋放通知請求。圖8中與參照圖4、5、6和7已經討論的步驟等效的步驟將不再被進一步描述。
在圖8的步驟S40中，應用程序APP3發(fā)出資源獲取請求，這比在步驟S5中已經發(fā)出其自身的資源獲取請求的應用程序APP2更遲。資源管理器在步驟S40中從應用程序APP3接收該資源獲取請求。在于步驟S30中從應用程序APP1接收釋放完成通知和釋放通知請求之后，資源管理器在步驟S41中確定在應用程序APP2與APP3之間是否有資源沖突。在此情況下，資源管理器在步驟S42中將獲取完成通知發(fā)送到具有最高優(yōu)先級的應用程序APP3。在步驟S43中，資源管理器將未成功獲取通知發(fā)送到應用程序APP2。在步驟S44中，應用程序APP3獲取所需資源。
在完成其處理之后，應用程序APP3在步驟S45中釋放它已經使用的資源。在步驟S46中，應用程序APP3將釋放完成通知發(fā)送到資源管理器。
當收到該釋放完成通知時，資源管理器在步驟S47中檢驗該釋放等待列表中所含的內容。從該列表中，資源管理器發(fā)現(xiàn)應用程序APP1已經發(fā)出釋放通知請求。隨后，進行由圖7中的步驟S32至S37構成的處理。
如上所述，體現(xiàn)本發(fā)明的資源管理器通過在保持當前使用狀態(tài)(條件)的情況下動態(tài)地實現(xiàn)優(yōu)先級和使用權管理來提供靈活的資源管理工具。換而言之，本發(fā)明的資源管理器以這樣的方式管理資源使用權，使得可靈活地定義實際使用硬件資源的應用程序以及被提供使用資源的權利的應用程序。
上述實施例引入了作為單位的“功能”的概念，該單位是資源使用權管理的增量，每個功能是由單個的硬件資源中用于構成應用程序而必需的多個資源構成的。本發(fā)明的資源管理器由此允許逐個功能地進行資源管理。
上面的實施例具有考慮到應用程序和資源的優(yōu)先級的請求隊列。與簡單的后進先出算法相比，該實施例使得能減少徒勞的資源沖突的數(shù)量。
盡管上面的描述包含許多特定方面，但是這些不應當被理解為限制本發(fā)明的范圍，而是僅提供本發(fā)明的目前優(yōu)選實施例的說明。應當理解，在不脫離所附權利要求書的實質或范圍時，可進行變化和變形。
例如，本發(fā)明可不僅應用于移動終端，而且應用于個人計算機和PDA(個人數(shù)字助理)。
關于圖1中的對應表，每當應用程序4發(fā)出資源獲取請求時，與給定的應用程序4所需的功能有關的以及與對應于這些功能的資源有關的信息可由所涉及的應用程序4發(fā)送到資源管理器1。
而且，優(yōu)先級不僅可應用于應用程序，而且應用于功能或者應用于每個功能中所含的資源。在這樣的情況下，資源管理器1可關于給定的功能或者關于該功能內的每個資源來確定是否有資源沖突。資源管理器1然后可考慮到資源沖突確定的結果而發(fā)出資源獲取完成通知和其他通知。
權利要求
1.一種資源管理方法，用于具有多個處理裝置的資源管理設備，所述資源管理方法包括步驟從所述多個處理裝置的任一個接受資源獲取請求；確定與來自所述一個處理裝置的所述資源獲取請求相應的資源是否與將由另一處理裝置使用的資源沖突；決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；當從未被給予使用所述資源的許可的處理裝置收到有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；當從已被給予使用所述資源的許可的處理裝置收到說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及將說明所述資源已被獲取的獲取完成通知發(fā)出到在所述列表檢查步驟中從所述列表檢查出的所述釋放通知請求處理裝置。
2.根據(jù)權利要求1的資源管理方法，其中所述決定步驟按照為每個所述處理裝置預定的優(yōu)先級來決定是否給予使用所述資源的許可。
3.根據(jù)權利要求1的資源管理方法，其中所述接受步驟逐個功能地接受所述資源獲取請求，該功能代表進行所需處理而需要的至少一個資源；其中所述確定步驟逐個功能地確定資源之間沖突的存在；其中所述決定步驟逐個功能地決定是否給予使用資源的許可；其中所述列表編目步驟逐個功能地在所述列表中對所述資源編目；其中所述列表檢查步驟逐個功能地檢查所述列表；以及其中所述通知發(fā)出步驟逐個功能地發(fā)出所述獲取完成通知。
4.根據(jù)權利要求3的資源管理方法，其中所述決定步驟按照每個功能預定的優(yōu)先級來決定是否給予使用所述資源的許可。
5.一種資源管理設備，具有多個處理裝置，所述資源管理設備包括接受裝置，用于從所述多個處理裝置的任一個接受資源獲取請求；沖突確定裝置，用于確定與來自所述一個處理裝置的所述資源獲取請求相應的資源是否與將由另一處理裝置使用的資源沖突；決定裝置，用于決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；列表編目裝置，其當從未被給予使用所述資源的許可的處理裝置收到有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；列表檢查裝置，其當從已被給予使用所述資源的許可的處理裝置收到說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及通知發(fā)出裝置，用于將說明所述資源已被獲取的獲取完成通知發(fā)出到由所述列表檢查裝置從所述列表檢查出的所述釋放通知請求處理裝置。
6.根據(jù)權利要求5的資源管理裝置，其中所述決定裝置按照為每個所述處理裝置預定的優(yōu)先級來決定是否給予使用所述資源的許可。
7.根據(jù)權利要求5的資源管理裝置，其中所述接受裝置逐個功能地接受所述資源獲取請求，該功能代表進行所需處理而需要的至少一個資源；其中所述沖突確定裝置逐個功能地確定資源之間沖突的存在；其中所述決定裝置逐個功能地決定是否給予使用資源的許可；其中所述列表編目裝置逐個功能地在所述列表中對所述資源編目；其中所述列表檢查裝置逐個功能地檢查所述列表；以及其中所述通知發(fā)出裝置逐個功能地發(fā)出所述獲取完成通知。
8.根據(jù)權利要求7的資源管理裝置，其中所述決定裝置按照每個功能預定的優(yōu)先級來決定是否給予使用所述資源的許可。
9.一種資源管理設備，具有多個應用程序、資源管理器訪問庫和資源管理器處理模塊；其中所述資源管理器訪問庫包括接受模塊，用于從所述多個應用程序的任一個接受資源獲取請求；以及通知發(fā)出模塊，用于將說明資源已被獲取的獲取完成通知發(fā)出到所述多個應用程序的任一個；其中所述資源管理器處理模塊包括沖突確定模塊，用于確定與來自所述應用程序的所述資源獲取請求相應的資源是否與將由另一應用程序使用的資源沖突；決定模塊，用于決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；列表編目模塊，其當從未被給予使用所述資源的許可的處理裝置收到有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；以及列表檢查模塊，其當從已被給予使用所述資源的許可的處理裝置收到說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及其中所述資源管理器訪問庫將說明所述資源已被獲取的獲取完成通知發(fā)出到由所述列表檢查模塊從所述列表檢查出的所述釋放通知請求應用程序。
10.一種資源管理程序，可由具有多個處理裝置的資源管理設備讀取以執(zhí)行，所述資源管理程序使所述資源管理設備執(zhí)行包括如下步驟的處理從所述多個處理裝置的任一個接受資源獲取請求；確定與來自所述一個處理裝置的所述資源獲取請求相應的資源是否與將由另一處理裝置使用的資源沖突；決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；當從未被給予使用所述資源的許可的處理裝置收到有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；當從已被給予使用所述資源的許可的處理裝置收到說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及將說明所述資源已被獲取的獲取完成通知發(fā)出到在所述列表檢查步驟中從所述列表檢查出的所述釋放通知請求處理裝置。
11.一種存儲資源管理程序的存儲介質，該資源管理程序可由具有多個處理裝置的資源管理設備讀取以執(zhí)行，所述資源管理程序使所述資源管理設備執(zhí)行包括如下步驟的處理從所述多個處理裝置的任一個接受資源獲取請求；確定與來自所述一個處理裝置的所述資源獲取請求相應的資源是否與將由另一處理裝置使用的資源沖突；決定在資源使用方面被發(fā)現(xiàn)相互沖突的處理裝置中應當被給予使用所涉及的資源的許可的處理裝置；當從未被給予使用所述資源的許可的處理裝置收到有關通知所述資源的釋放的請求時，與該釋放通知請求處理裝置相結合地在列表中將相應于該釋放通知請求的所述資源編目；當從已被給予使用所述資源的許可的處理裝置收到說明所述資源已被釋放的通知時，從所述列表中檢查所述釋放通知請求處理裝置；以及將說明所述資源已被獲取的獲取完成通知發(fā)出到在所述列表檢查步驟中從所述列表檢查出的所述釋放通知請求處理裝置。
全文摘要
通過有效率和靈活地在應用程序之間分配資源，沒有沖突地實現(xiàn)資源的獨占使用。如果當應用程序APP1正在使用資源的同時從應用程序APP2接收資源獲取請求(步驟S5)，則資源管理器(ResMan)在應用程序APP1和APP2之間進行資源并發(fā)判斷(步驟S6)，并且具有較低優(yōu)先級的應用程序APP2返回獲取NG報告(步驟S7)。資源管理器從應用程序APP2接收資源釋放報告請求(步驟S9)，接著從應用程序APP1接收釋放完成報告(步驟S11)。資源管理器查看是否有對于該資源的任何其他沖突請求(在步驟S15中)。在沒有其它資源并發(fā)，則資源管理器向應用程序APP2發(fā)出資源獲取完成報告(步驟S16)。
文檔編號G06F9/46GK1806228SQ20048001618
公開日2006年7月19日 申請日期2004年6月9日 優(yōu)先權日2003年6月10日
發(fā)明者大出直樹 申請人:索尼愛立信移動通信日本株式會社