Thread 是可以視作程式流程的執行者
執行工作的情境其實沒有很複雜
- 執行工作
- 休息/恢復
- 等待工作執行完成
- 取消執行 (非強制)
- 雖然工作未完成,但強制中斷它,不執行了 (.NET Core 不支援 Thread 等級的中斷)
情境 1-1: 執行工作基本的 thread 建立語法
情境 1-2 : 使用 Thread 與 ThreadPool
情境 2-1: 休息與恢復
建立一個一開始工作就睡覺的 Worker (常見?)
然後 Manager
做完自己的工作就把Worker叫醒
但是感覺得出來並不是完全自由的控制
例如: Sleep 是由Worker控制,不是由外部控制
想要再次睡著也是很困難
如果 Worker 沒有睡著,但是Manager先去 Interrupt 它也會出錯
情境 2-2: Suspend & Resume (無效)
以前是可以用的 但是現在已經停用了
https://docs.microsoft.com/zh-tw/dotnet/api/system.threading.thread.suspend?view=net-5.0
裡面的理由是因為停止執行緒的時候,會不曉得執行緒裡面的程式碼執行到哪裡
建議使用 Monitor, Mutex, Event, Semaphore等等來達到效果
情境 3: 等待工作執行完成
thread.Join() 有點等待thread抵達的意思
也有可能執行緒在之前就睡著或是消滅了,導致根本不會抵達喔
情境 4: 取消執行(非強制)
.NET 4 之後提供了一個 CancellationToken 來讓我們註記工作的取消
但是仔細想過之後會發現
這些機制其實已經跟
Thread 脫鉤了,只是把取消的機制傳送至工作流程中
不再跟 worker 有關(還記得
Thread 是工作的執行者嗎?)
反而跟 job 有關也就是由流程自己來管理了
個人猜測也是跟整體模型的變更有關係 (Task為主)
所以讓原來控制 Thread 的
Suspend 跟 Resume 也棄用了
沒有留言:
張貼留言