有時候技術人員之間的差異微乎其微,但就是這微乎其微的差異積少成多,讓我們與大牛之間的距離越來越遠,當你開始在意這些細節而不是只關注成長的速度的時候,時間會告訴你當前版本的答案,技術的積累會產生難以想象的質變。大鵬一日同風起,然后一直起!起!起?。ǔ哆h了...回歸主題)。
會用和看懂是兩個概念,假如你不趕時間的話,我愿用我蹩腳的解釋,帶你去看看作者的匠心獨具。先上第一段熱乎的代碼:
語言的盡頭并不是C語言,機器無法執行一段C代碼,她需要經編譯,匯編等等操作最終形成可執行的機器碼,當然我們是看不懂的,所以我們要理解,C語言首先要變成匯編代碼,那么一條語句就可能編程好幾句。
當你從裸機編程切換到OS調度機制的時候,本質上來講比單純的裸機,CPU需要執行的代碼更多更復雜了,機器的性能相對是降低了,為了盡量降低這種額外的開銷,于是就出現了開局default的操作,這完全是站在機器的角度上選擇結果,軟件少一次的case判斷,變成匯編語言就是可以少執行好幾條語句,節省掉多個機器周期。
接下來:讓我們看一下兩種運行任務的方式:
//運行任務
#define RunTask(TaskName,TaskID)
do
{
if (timers[TaskID]==0)
{
TASK d=TaskName();
while(timers[TaskID]!=d)
timers[TaskID]=d;
}
} while(0);
//運行任務,前面的任務優先保證執行
#define RunTaskA(TaskName,TaskID)
do
{
if (timers[TaskID]==0)
{
TASK d=TaskName();
while(timers[TaskID]!=d)
timers[TaskID]=d;
continue;
}
} while(0);
先看下任務是如何運行的,先判斷該任務對應的阻塞時間是否到達:
1. 沒到達的情況下,不運行任務,結束執行。
2.時間到,timers倒計時為0,執行任務,并返回阻塞時間,第一個細節操作來了,先判斷timers是否等于返回的阻塞時間,如果不等于則進行賦值,這里是不是多此一舉,不用判斷直接賦值多好,去掉while判斷。你能這么想是因為你站在程序員的角度上,換一個角度,你站在機器的角度上來考慮問題,while判斷和賦值操作的運行時間,假定賦值操作需要更多的執行時間開銷,那么加一條while判斷,再相等的情況下,是否就不需要執行賦值操作了,可以節省更多的操作時間,二當需要賦值的情況下,可能也就加一條簡單的判斷操作,我是這樣的理解的,當然也可能不對,只是給你提供一條思路。
對比任務和函數的區別:函數的返回值一般給到的是變量,作為函數執行的輸出(當然是純軟的情況下,有硬件參與的情況下,更多的是硬件對應的執行動作),任務的返回值的意義是:阻塞時間,將值記錄到任務對應的timers數組中,提供給任務框架進行計時操作。
RunTask和RunTaskA的最大區別,就是continue的操作,執行完任務后,理論上任務返回的阻塞時間可以是任意值,當返回值為0時,代表著任務并未阻塞,這個是帶有continue操作的任務將會重新運行該任務,也就是TaskA優先保證執行。