1.執行時系統相關模組
這一節只講述排程系統。
2. 與排程相關的有下列資料有：
(1)全域性表就不用多解釋， 排程器不是乙個專門的執行緒，而是一種資源，每個m都可能會對其進行查詢，如：m的呼叫的時候，會首先查詢排程器中的可執行佇列g，然後查詢本地p執行佇列; 在m不夠的時候，會首先排程器空閒的m列表中查詢; 在程式執行過程中，使用
runtime.gomaxprocs
介面設定p上下文數量的時候，會動態的增長p的數量，這些p就是加入到排程器的空閒列表。
(2)m每次呼叫g的時候，必定需要乙個上下文p，因為當呼叫的時候，可能會產生另外的g，其g的取得的步驟為， 從當前p自由g列表中取-> 從排程器自由g列表中取 -> 全域性分配。當然，當該p執行完乙個g後，會首先加入到p自由g列表，然後超過數量則加入到排程器自由g列表中。
3. m,p,g的對應關係
m 預設是多個， 也就是對應多個os執行緒，無狀態變化，唯一的變化就是是否在空閒佇列中。
3.1 p的狀態介紹
p可以通過runtime.gomaxprocs設定，一般不用設定。p具有狀態：
狀態機如下：
(1)m與p關聯後，會從pidle -> prunning
(2)p變成pdead狀態，只有使用者設定了p的數量減少了
3.2 g的狀態介紹
狀態機圖：
(1)grunning -> gwaiting 這個狀態是golang自己的channel接收機製造成
(2)grunning-> gsyscall 是該協程使用了某些系統呼叫，如io讀取，所以直接掛起，使用的是非同步io阻塞機制
4. m,p,g執行過程：
注意：上面的全力查詢注釋有誤，為沒有則 m會掛起阻塞，然後等待被其他m喚醒
其中，全力查詢可執行g的過程會通過以下幾步
(1)查詢本地p可執行g佇列
(2)從排程器可執行g佇列查詢
(3)從網路io輪詢器中查詢就緒g
(4)偷取別人的本地p可執行佇列g
(5)再次查詢排程器中的可執行g
(6)嘗試從所有p中查詢可執行佇列g
(7)再從網路io輪詢器中查詢
實在不行，就把自己和p解除聯結，放置到排程器空閒佇列中，並且阻塞。
其中查詢到多個執行g之後的流程圖如下：
5.g io操作的執行過程
(1)當g執行io操作後， 並且如果
該g和m已經繫結，那麼g阻塞（阻塞只是打個標記，並不是阻塞當前執行緒），io請求由io輪詢器進行，然後m繼續執行
，把當前的p解除關聯，m阻塞等待，當io輪詢器執行完後，然後g變成可執行狀態，當其他的m找到這個繫結m的g，會把自己的上下文p解除聯結，並且喚醒繫結的m，然後繼續執行。
注意：當未使用g和m繫結的時候，就不會執行喚醒其他m的操作
uCOS II任務排程過程
uc os ii的任務一般格式為 void taskn void pdata ucos ii是基於任務優先順序搶占式任務排程法的，就是核心在管理排程時，呼叫任務切換函式 一般為ssched 在該函式中將此時已處於就緒狀態 條件一 並且為最高優先順序 條件二 的任務的儲存於其棧中的相應資訊壓入cpu暫...
Yarn資源排程過程詳細 TEZ
在mapreduce1.0中，我們都知道也存在和hdfs一樣的單點故障問題，主要是jobtracker既負責資源管理，又負責任務分配。yarn中可以新增多種計算框架，hadoop,spark,mapreduce,不同的計算框架在處理不同的任務時，資源利用率可能處於互補階段，有利於提高整個集群的資源利...
三 JBPM流程引擎核心排程過程
其中execute 方法，針對不同的節點，內容就不一樣，比如 fork節點 根據有幾個transition，就生成幾個subtoken，分別指向那幾個transition，然後為roottoken的childs屬性新增剛剛那個幾個transition join節點 判斷所有subtoken是否都到達...