thread只是一個當前工作所要執行的任務...
一般程式會有一個進入點..
之後會執行一些相關操作, 例如建構子初始化之類的...
這時候會存在一個主執行緒來handle...
主執行緒在過程中, 可能會生成其他的執行緒來操作其他任務...
例如worker thread, background thread之類的..

我可以說我生成一個thread, 這個thread是用來執行某一個任務..
例如從DB撈取資料...
如果沒有生成其他thread來並行化, 那麼程式必須等待當前執行緒完成任務...

thread是可以被切換, 像是我main thread執行一般任務, 結果使用者可能觸發某個事件..
例如一個程式包含眾多使用者使用, 那如果這些使用者被目前的程式管理(觀察)..
有一個user點擊某個按鈕觸發某個事件希望能通知其他使用者..
但是我又不想按下去後, main thread要等待這個事件完成, 否則程式會整個暫時hang住(當前的user無法做任何事情)...
因此我可以透過觸發這個事件時, 生成另外一個thread去切開執行通知使用者的任務...
main thread不用進行等待, 可以做其他事情. 直到通知使用者的thread完成操作, 可能會執行所謂呼回(callback)的操作讓main thread知道有一個thread已經完成操作, 並且依據這個callback的內容執行後續操作..

thread一般是要被管理的, 否則會天下大亂...
不管是user-based也好, kernel-based也好...

OS那是歸OS的事情, 但是使用者程式那又是另一回事...
那麼使用者的應用程式怎麼管理thread?..
1. 根據API的環境管理. 沒辦法! multi-thread這塊, 老子自認做不來.
2. fuxk, 老子就是屌. 自己動手豐衣足食, 自己來管.

1 的情況可能就要看程式所使用的API多屌了.
例如透過API環境會有一個pool來管理.
這一切不用開發者做太多干預. 開發者只要把目前的thread放進這個pool就好.
沒辦法! 老子自認貧窮限制了我的想像.

2 的情況. 開發者自認自己做得來, 自己管. 那麼開發者必須了解一些事情
a.目前程式所使用的API能在這塊給他多大好處
b.開發者理解了thread的相關知識
c.開發者熟悉thread這方面的 "設計模式". 自己認為有本事做得好.
d.老子TM就是爽, 你API管我那麼多幹啥阿.