Windwaker wrote:
我建議你去看看OS裡面Thread Pool的定義
....
Threadpool是Windows用來根據不同的Thread dependency排程不同的Worker Thread
然後再來看看你寫的....
....
A thread pool is a collection of worker threads managed by the operating system to schedule and execute asynchronous operations on behalf of an application.
不相干的到處套在一起，本來就是W大的大絕招。這次鬧的笑話是把Thread Pool跟Thread Queue搞在一起......想必W大看到"schedule"那個字、聯想到之前自己鬧的Task Scheduler的大笑話所造成的陰影，心中一揪就開槍了.....
前面從一百多樓就開始講的一直是Windows核心內被嚴密保護的執行緒排程程式，原來核心裡面重要的執行緒排程程式、跟多條不同優先權的Thread Queues，還是要跟這類集合了應用程式特定非同步工作執行緒的Thread Pool扯在一起，不愧是W大。這就像談到社會大眾整體利益，W大就會提到"可是我家寵物狗狗特案需求不同、如何如何"....
下面這是應用程式不能介入、在系統核心被嚴密保護、管理所有排程跟執行的執行緒排程程式與Thread Queue的說明：
http://msdn.microsoft.com/en-us/library/ms682105(v=VS.85).aspx
這是"特定"應用程式有需求的Thread Pool說明：
http://msdn.microsoft.com/en-us/library/ms686760(v=VS.85).aspx
[懶人包整理]
Windwaker wrote:
幾乎大部分的軟體都是單核
只有像轉檔，遊戲這兩類程式
程式設計師才會有需求去搞多線程
一開始的爭點很單純，在於W大師硬是堅持"大部分軟體都是單核"，雖然語句不通、軟體也沒有"核"，但大致可以知道W大師要表達的是"大部分軟體都是單執行緒"。要驗證這一點，只要從工作管理員的"處理程序"那一頁自行加入"執行緒"欄位，就很容易可以看出現實世界剛剛好跟大師說的相反：大部分軟體都是多執行緒的，並非只有遊戲跟轉檔軟體兩類才有多執行緒的需要。不過這點被戳破後，W大師開始惱羞成怒，因此才有後面幾百樓的鬼打牆跟一再張冠李戴的資料引用、甚至自打嘴巴。
========================================================
微軟對於工作管理員的說明：
http://windows.microsoft.com/zh-TW/windows7/What-do-the-Task-Manager-memory-columns-mean
"在 [工作管理員] 中，您可以將欄位新增到 [處理程序] 索引標籤所顯示的資訊中，藉以監視電腦上執行的處理程序。這些欄位會顯示有關每個處理程序的資訊，例如處理程序目前使用多少 CPU 與記憶體資源。"
| 欄位 |
說明 |
| 執行緒 |
處理程序中執行的執行緒數量。 |
========================================================
話說W大惱羞成怒後，這一路為了硬拗自己的說法正確、馮京當馬涼亂引用參考資料、甚至搬磚砸自己腳的例子，輕微的不計，重大的笑話至少有以下了：
1. 在161樓前後，當時W大心中還沒有Windows內部存在有執行緒排程器、進行所有執行緒排程的作業系統基本觀念，為了圓自己"程式會自行分派執行緒到核心執行"的說法，看似很有學問的舉出ACM異質核心處理器的論文，來張冠李戴到Intel/AMD這種同質性核心處理器上，幾經提示，還是搞不清楚錯在哪。
2.一直到235樓，W大一路趕快找Thread排程的資料惡補，不過卻找到了星期一備份、星期二掃毒....的Windows公用程式Task Scheduler工作排程器身上去，把它當成是Windows內部極度重要的執行緒排程器（已經自爆改文了，不過sambad兄在236樓有護貝）。
3. 另外W大喜好提出一堆不見於文獻的名詞，例如"Sequential Multi-thread"、"Data Thread"，但卻從不嚴謹定義之，又提出"Sequential Multi-thread程式的執行緒，都會跑到同一個核心上" 的獨特"假說"（比如像SP2004這種沒人知道程式設計師當年是如何寫的程式，W大剛好拿來魚目混珠...），後來288樓W大引用在微軟官方網頁找到的Windows Thread排程邏輯，其實就已經否定了自己的"假說" 。微軟網頁是這麼說的：
========================================================
"Under the SMP model, any thread can be assigned to any processor. "
"在這種同質性處理器/核心的系統上，執行緒可以被（系統排程器）指派到任何的處理器/核心上（執行）"
========================================================
W大在274樓跑SP2004的貼圖，只有Thread Count那頁，但就是沒有貼"效能"那一頁（其中包括在不同核心上的使用率記錄），可能是擔心會否定掉獨家定義的"Sequential multi-thread程式只會在同一個核心上執行"的"假說"（"例如"(？？？)死無對證的SP2004.....原程式設計師曰：我躺著也中槍......）。
實際動手實驗結果，圖中SP2004有五個執行緒：
執行過程中，SP2004的執行緒在Round-Robin重新排程過程中，都有機會被分派到不同核心執行，燒機執行緒特別明顯。
不管是看圖、不管是W大自打嘴巴引用的微軟官方網頁、或根據下面微軟PPT檔白紙黑字的Windows執行緒排程邏輯，全部否定"必定分到同一核"的發生。就算程式設定了Affinity，也絕對不保證跑在同一核上，W大卻硬是要多凹了好幾百樓。
Windwaker wrote:
也難怪你會叫人家看Thread Count來決定該軟體支不支援多核心平行運算....
Process Thread Count > 1，為多執行緒程式，不先寫成多執行緒程式，免談接下來進行執行緒負載平衡、追求多核心平行運算帶來的效能及回應速度增進。要說多執行緒跟平行性分析是不是免費午餐，我從63樓就提到程式設計師功力跟經驗很重要，W大的獨特腦袋，硬要自行曲解成"ycweng說看工作管理員執行緒數>1就是完全支援多核"。不過"完全支援多核"這種沒有明確定義的詞句，是W大的大剌剌風格，不是我的用語...
....要怎麼個完全法？沒有定義，你的"完全"跟我的"完全"、還有每個人不同的"完全"，會一樣嗎？Windows核心排程程式是以執行緒為單位，分派執行緒到多核處理器的不同核心執行。如果執行緒間平行性很高，分到多核執行負載很均勻，整件工作完成時間縮短，那最好；如果執行緒間工作分配極度不均（像SP2004這種），但是執行緒間仍舊有獨立性（例如：燒機中仍可操作UI而沒有頓呆感覺、燒機進行時UI執行緒仍然持續更新程式畫面上的資訊），那試想：
ycweng wrote:
1. 如果專案中有一個人負擔了90%的工作（燒機Thread），其他人負擔了其他10%（其他獨立Threads），但彼此可以平行進行（可在不同核心上執行），相對於把90%的工作+10%的工作都放在同一個人（單核心處理器）身上，請問專案完成時間，只會更多，還是更少？
2. 換一個角度問，給定一段時間，有分工的平行專案（即使分工不均也算）、跟沒分工一個人搞的情況，能做的事比較多的，是哪一種？
...(恕刪)
既然W大師一直迴避不敢答，那就不用回答了....
一般Windows系統內的所有系統程式/應用程式的執行緒數量加總，隨時都有成千上百執行緒等待/待命被執行。即使不是每件工作、每個程式都能完美平行化，但一旦尖峰時間來臨，八線道的高速公路，單位時間內總運輸能量仍比二線道、單線道高出許多。
W兄您再慢慢東拉西扯，很清楚你的張冠李戴剪貼把戲啦！至少小弟不會把Task Scheduler工作排程器當成執行緒排程拿出來說嘴......
，等換頁再貼懶人包置頂.....
