任務輸入佇列

任務輸入佇列

佇列,是先進先出(FIFO, First-In-First-Out)的線性表。是一種常用的數據結構,在具體套用中通常用鍊表或者數組來實現。佇列只允許在後端(稱為rear)進行插入操作,在前端(稱為front)進行刪除操作在計算機中,任務的定義主要取決於處理任務的對象。例如對於CPU來說,等待處理執行緒或進程就是它的任務。任務輸入佇列是指用於存放尚未處理任務的佇列。一般任務的不同,任務輸入佇列的優先權是不同的。

簡介

在計算機中,任務輸入佇列是指存放待處理任務的佇列,在計算機中,任務的重要性是不同的,因此任務需要分類,例如在實時系統中,由於在實時系統中都存在著若干個實時進程或任務, 它們用來反應或控制某個(些)外部事件,往往帶有某種程度的緊迫性 ,根據緊迫性的程度把任務分成硬實時任務和軟實時任務。因此作業系統根據任務的緊迫性或優先權不同,把任務加入任務不同優先權輸入佇列中,或者在處理任務時根據任務優先權選擇哪個優先處理。這種佇列,可以稱做優先權佇列。

不同優先權佇列是指按照優先權將分成不同的佇列,每一個佇列對應一種優先權。優先權是指計算機在處理多個作業程式或任務時,決定各個作業程式或任務接受系統資源的優先等級的參數。

優先權佇列

優先佇列是計算機科學中的一類抽象數據類型。優先佇列中的每個元素都有各自的優先權,優先權最高的元素最先得到服務;優先權相同的元素按照其在優先佇列中的順序得到服務。優先佇列往往用堆來實現。

如果我們給每個元素都分配一個數字來標記其優先權,不妨設較小的數字具有較高的優先權,這樣我們就可以在一個集合中訪問優先權最高的元素並對其進行查找和刪除操作了。這樣,我們就引入了優先權佇列 這種數據結構。 優先權佇列(priority queue) 是0個或多個元素的集合,每個元素都有一個優先權,對優先權佇列執行的操作有(1)查找(2)插入一個新元素 (3)刪除 一般情況下,查找操作用來搜尋優先權最大的元素,刪除操作用來刪除該元素 。對於優先權相同的元素,可按先進先出次序處理或按任意優先權進行。

優先佇列至少需要支持下述操作:

插入帶優先權的元素(insert_with_priority)

取出具有最高優先權的元素(pull_highest_priority_element)

查看最高優先權的元素(peek):O(1) 時間複雜度

其它可選的操作:

檢查優先權高的一批元素

清空優先佇列

批插入一批元素

合併多個優先佇列

調整一個元素的優先權

監控軟體排隊應用程式的系統和方法

某些網路通信標準比如FDDI、BISDN和SONET出現之後,京(十億)位計算機通信之日就到了,而且太(萬億)位通信之日也為期不遠。這些高速網路環境需要新的和強有力的工具,它們根據從網路獲取的信息,有助於網路設計、網路管理、網路控制功能以及網路服務。這些高速環境中一個至關重要的問題,是監控來自一個或多個高速通信通道的原始數據,以及把這種數據轉換為對一個用戶、對一項服務有用的“信息”,作為對一種算法(需要時必有)的一個輸入,諸如此類。

迄今為止,這個問題已經被視為“實時”網路監控和性能評價條件。網路監控通常定義為對於一個系統的運行,提取、處理、收集和呈現動態信息。那么,網路性能管理分析員就使用監控信息,實時地評價網路資源的狀態,通常是只有一個人面對計算機顯示,分析監控信息。

管理大型聯網結構的需求之一,是監控眾多的不同應用程式,它們遍及一個可能包括天壤之別平台的計算機網路,負責信息傳輸。

在這些應用程式中,有一些是後台任務,通常這樣稱它們是因為它們並不呈現用戶界面。對於在各種系統之間負責信息傳輸的後台任務,需要了解其特性信息。實際上,應用程式的操作員需要了解一項傳輸是否成功,以及傳輸是否遇到問題或瓶頸。遺憾的是,後台任務並不提供任何狀態信息,因此應用程式的操作員無法判斷應用程式是否工作正確無誤。

對於各種各樣的應用程式傳輸,一種廣泛使用的方法是訊息佇列。訊息佇列使得分散式應用程式能夠交換訊息,無論硬體和軟體資源如何。在訊息佇列系統中,傳送方應用程式不必考慮傳遞路由,也不必了解接收方應用程式何時拾取這些訊息。接收方應用程式能夠在適當的時機拾取新的訊息,而不必與傳送方應用程式保持一種直接聯繫。如果需要,接收方應用程式也能夠確認收到了訊息。

訊息可以在應用程式之間同步或異步流動。同步模式允許傳送方應用程式收到接收方應用程式的回答之後再繼續。訊息在應用程式之間流動時,也能夠以一對一的模式、一對多的模式、多對一的模式或者任何組合進行。

一般說來,一個訊息應用程式包含兩個部分:應用程式數據和訊息標識數據。訊息可以由幾種參數來標識,比如訊息的類型、應用程式的數據長度和訊息的優先權。

已知有幾種方式來監控訊息應用程式及其資源。商業產品如Tivoli System公司的Tivoli和IBM公司的Omegamon都能夠監控佇列以及確定應用程式的狀態。利用這些產品,應用程式的操作員必須持續不斷地穿行在多個面板之間,以便找到採取適當措施所需的參數。在這樣做時,就有一種風險——忽略了應用程式中發生的重要問題。

其它的商業產品,比如IBM公司的MQSeries和CICS,提供了若干方式來判斷佇列的深度和應用程式的狀態。

授予Bonnell等人的5,655,081號美國專利公開了一種系統,用於在整個分散式計算環境中,使用一種智慧型的自主代理架構來監控和管理計算機資源和應用程式。如同上述的產品,當一個佇列中包含預定數目的無應用程式標識的訊息時,這種系統也能夠觸發一條警告訊息。

不過,今日的工具都沒有為操作員提供獨特的界面,對於要監控的特定應用程式,匯集相關的任務狀態和佇列深度。相反,已知的系統都是提供整個系統中所有應用程式的信息。

所以,需要為應用程式的操作員提供一種單一的系統,它對一個應用程式和正在使用的資源,匯集了相關的所有信息。

一種計算機實施的方法,用於在運行著至少一個處理任務的訊息排隊傳輸系統中,監控上游和下游軟體應用程式,本方法包括以下步驟:在一個訊息排隊傳輸系統之內,通過把一個輸入佇列組標識符分配給第一輸入佇列和分配給第二輸入佇列,形成第一佇列組;在這個訊息排隊傳輸系統之內,通過把一個輸出佇列組標識符分配給第一輸出佇列和分配給第二輸出佇列,形成第二佇列組;把第一佇列標識符分配給第一輸入佇列,第二佇列標識符分配給第二輸入佇列,第三佇列標識符分配給第一輸出佇列,第四佇列標識符分配給第二輸出佇列;在這個訊息排隊傳輸系統之內,把一個任務標識符分配給一個處理任務;確定第一輸入佇列中存放的第一訊息數目,第二輸入佇列中存放的第二訊息數目,第一輸出佇列中存放的第三訊息數目以及第二輸出佇列中存放的第四訊息數目;確定處理任務的活化狀態;以及在一個任務監控器存儲區域,匯集第一輸入佇列中存放的第一訊息數目,第二輸入佇列中存放的第二訊息數目,第一輸出佇列中存放的第三訊息數目,第二輸出佇列中存放的第四訊息數目以及處理任務的活化狀態。

相關搜尋

熱門詞條

聯絡我們