hkdennis2k wrote:
不, 用 multi-thread 主要絕對不是為了共用資源

sam_huang74_pc wrote:
MultiThread 基本上會牽涉到 OS 跟 CPU...等等的運作,所以他並不等同於開越多速度越快,甚至如果開太多反而會造成Thread之間轉換所造成的效能耗損,所以我的建議是實際上去測試一下會比較準.尤其在PC跟SERVER上就有很大的差別.

Duncan wrote:
假如不考慮 multi-task 操作在 OS 層面的額外成本，multi-task 去執行一個任務會不會比單一 task 來作來的快，還得看 I/O 或更廣義地說是 resource 的使用情形。

比如說，假如一定要用洗衣機洗衣服，在只有一台洗衣機(resource, I/O)的情況下，一個人洗 50 份衣物(假設一台洗衣機的負載剛好是一份衣物)，跟 50 個人同時並進來洗自己所持有的一份衣物，何者會比較快完成 50 份衣物的清洗？假如衣物是用手洗呢？

Duncan wrote:
你提到的是 pipeline 的概念，但我覺得不適合拿來比喻 multi-task(一個人洗衣服還是可以同時利用一台洗衣機洗衣，一台烘衣機來烘衣)。我是把多人同時做事比喻為 multi-task，洗衣機則是有限的資源或是有限的 I/O 能力。

一個任務該以 single-task 方式還是 multi-task 方式來運作，除了整體上的效能外，還要考慮 runtime 表現何者較適合應用需求而定。你提到你的 server 只用 single thread 來接受 client 連結(包括後續操作)，如果以數據的傳輸量來說，多個 thread 同時處理多個 client 可能在整體的數據傳輸效率上好不了多少(這還得考慮很多因素)，但是假如一個 client 建立的 session 是很花時間的，我想多數的應用都不會接受這種一個 client 服務完才服務下一個 client 的行為(FTP server 如果這樣搞，你受的了嗎？)。反過來說如果你能使用單一 thread 而對多個 connection 分時作 I/O，使用單一 thread 並沒有什麼不好。

Duncan wrote:
但我的重點是：效率不是唯一的考量。(我提到你能接受一個 FTP server 一旦有 client 連接上之後必須要等到這個 client 把要下載/上載的數據傳完才服務下一個 client 的這種表現嗎？就是這個意思)

honeyaaa wrote:
是的，就如您所說的，這是Server開multi-thread最主要的功用，呼。受教

老實說，我在和別人解說multi-thread功用時，已經快變成爭論了 >.<
(因為別人一直拿效率點來爭論)
我一直提到開在多的Thread再同一時間只有執行一件事，所以不可能有快n倍這種觀念，
並且也一直在說明就算快也是只有快在時間差，(因為別人一直拿效率點來爭論)，
卻忘了最簡單也最重要的意義。