TWed2k - 程式開發討論區 - [問題]問問timer與執行序的觀念C#

Litfal
銀驢友〔初級〕

寫奇怪的程式中

．積分： 486
．文章： 322
．收花： 4068 支
．送花： 3976 支
．比例： 0.98
．在線： 965 小時
．瀏覽： 7522 頁
．註冊： 6268 天
．失蹤： 3249 天

#1 : 2011-8-13 09:15 PM 全部回覆	送花 (3) 送出中...

這什麼時候的文章居然被挖上來XD
既然看到就來留個心得：

在開始說Timer之前，先提一點：
.NET限制能存取視窗控制項屬性的，只有建立該控制項的執行緒。
另外，我說明舉例的角色A、B、C都是以執行緒觀點來看，你也可以將其視為"工人"。

.Net提供的Timer有三個：
System.Windows.Forms下面有一個，Threading和Timers裡面各有一個。
除了這三個以外，用ThreadPool.RegisterWaitForSingleObject也可以自己實作Timer的東西。

System.Windows.Forms是靠註冊計時器，並使用Send Message的方式向Window Form觸發計時器耗盡事件。(計時器耗盡->發送訊息給Timer的所在Form->Form處理訊息->Form呼叫耗盡事件函式)
由於收到訊息的是所在Form的handle，所以一定能保證呼叫事件的，與該form的執行緒是同一個，可以隨意操作視窗控制項，而不會發生跨執行緒作業失敗。
感覺就像這樣：(A請B時間到叫他->B開始計時->B時間到叫A->A收到通知後去做某件事)。
由於B被封裝隱藏的很好，使用者會感覺A是自己計時自己做事的。
缺點：
1.訊息是以Message Pump的方式序列在一個緩衝區，Form的執行緒會一個接一個處理這些訊息；當你的視窗很忙的時候，你就不能確保計時器訊息會在第一時間被處理。
2.當你的計時器訊息觸發的是一個耗時工作時，耗盡事件時UI會停止回應直到工作完成；當然你可以另外建一個執行緒來處理耗時的部分，最後才將需要通知UI顯示的部分Invoke給UI執行緒，但你不覺得這樣拐彎抹角嗎？看看下面兩個工作案例：(A叫B時間到叫他->B開始計時->B時間到叫A->A收到通知叫C去做件事、做好叫他->C做好叫A)、(A叫B時間到做件事、做好叫他->B開始計時->B時間到做事->B做好叫A)，哪個比較複雜應該一目瞭然？這種情況就應該使用Threading.Timer。另外，建立執行緒也是件cost很高的作業。

Threading.Timer，則是結合計時與工作於一身。建立時就要告訴它時間到要做什麼工作，而不是事件委派；也就是說，建立後就不能改變工作了。建立時會從ThreadPool去要執行緒，也就是說，他和建立他的絕不會是同一個執行緒。
感覺就像這樣：(A到一群手下裡面隨便叫一個B、時間到去做某件事->B開始計時->B時間到->需要的話叫人做下一次的工作*有可能是自己->B開始工作)
所以使用上要注意到，有些狀況要使用Invoke通知建立執行緒。

Timers.Timer則專職計時，時間到了就把工作用事件委派下去，接下來他完全不管。
感覺就像這樣：(A請B計時並派定工作->B時間到了將手上的工作(事件)分別叫個工人來做->B繼續他的計時作業)
所以用時和Threading一樣要注意跨執行續作業。

Threading和Timers提供的Timer用起來其實蠻像的，差別在於
1. Threading.Timer 更輕量。
2. Timers.Timer 通常較準確一些、Threading.Timer 可能被一些奇怪的鎖定狀況影響進度。
3. Timers.Timer 可以利用事件做多重委派、或是改變工作。

一般我是這樣決定使用時機：
1. 耗時、須多重委派 -> Timers.Timer
2. 多執行緒關係複雜，且須精確觸發 -> Timers.Timer
3. 與Form有關、非耗時工作 -> Form.Timer
4. 其餘 Threading.Timer

累了，關於Invoke和BeginInvoke，下次再說吧。

[Litfal 在 2011-8-13 09:20 PM 作了最後編輯]

[如果你喜歡本文章，就按本文章之鮮花～送花給作者吧，你的支持就是別人的動力來源]

本文連接

快速回覆