1. 程式人生 > >[CareerCup] 16.2 Measure Time in a Context Switch 測量上下文轉換的時間

[CareerCup] 16.2 Measure Time in a Context Switch 測量上下文轉換的時間

16.2 How would you measure the time spent in a context switch?

上下文轉換髮生在兩個程序之間,比如讓一個等待程序進入執行和讓一個執行程序進入等待,這些在多工中發生。作業系統需要把等待程序的資訊放入記憶體和把當前執行的程序資訊儲存下來。為了解決這個問題,我們記錄在切換程序時的最後和第一個指令的時間點,比如我們有兩個程序P1和P2,P1在執行P2在等待,當我們切換P1和P2時,假設發生在P1的第N個指令,我們用tx,k來表示程序x的第k個指令的時間點,那麼切換的時間為t2,1-t1,n

那麼問題是我們怎麼知道什麼時候轉換髮生,我們又不能記錄程序的每個指令的時間點。另外還有轉換是由作業系統的安排演算法管理的,而且有很多核心執行緒也要用上下文轉換。其他程序也可能競爭CPU或核心處理中斷。使用者不能控制外部的上下文轉換,比如在時間t1,n

,核心決定處理中斷,那麼上下文轉換的時間就會延長。為了克服這些困難,我們需要建立一個上下文使得P1執行完,P2馬上就能執行。我們可以建立一個數據通道Data Chanel,例如管道Pipe,在P1和P2之間,就像兩個程序在打乒乓球,使用資料權標Data Token。

我們讓P1當傳送者,P2當接受者。開始時,P2在等待,當P1執行了,它傳送了資料權標給P2,然後等著讀取一個回執。但是由於P2還沒能執行,所以P1沒有回執,進行被阻礙了,釋放了CPU。上下文轉換髮生了,任務分配器必須選另一個程序執行,且P2處於準備執行狀態。當P2運行了,P1和P2的角色互換了,P2現在是傳送者而P1是接受者,當P2發回執給P1,整個過程就完成了:

1. P2等待P1傳送訊息。

2. P1記錄時間點。

3. P1給P2傳送訊息。

4. P1試圖讀取回執,這包括了一個上下文轉換。

5. P2準備就緒並接到了訊息。

6. P2傳送回執給P1。

7. P2嘗試讀取P1的回執,這包括了一個上下文轉換。

8. P1準備就緒且接到了訊息。

9. P1記錄時間點。

那麼步驟2到9之間的時間差T,表示為T = 2 * (Td + Tc + Tr),其中Td和Tr表示傳送和接受訊息時間,Tc表示狀態轉換的時間。那麼現在問題是要求Td + Tr的值,即為P1傳送資訊給自己到接受到訊息的時間,這不包括狀態轉換的時間因為是發給自己。由於可能存在的未知中斷,所以我們需要重複多次,取最小的Tc

當做結果。

這也只是一個近似結果,因為我們這麼做有個假設就是當P2接到訊息後馬上就開始執行,這得根據任務分配器的實現方法,所以只是個近似值。