書上寫的工作隊列的實現是創建一個單獨的線程來執行相應的work. 但是最新的內核實現卻不是這樣的，原先的工作隊列的接口都快要廢棄了，
New API:
alloc_workqueue(name, flags, max_active)
alloc_ordered_workqueue(const char *name, unsigned int flags)
{
return alloc_workqueue(name, WQ_UNBOUND | flags, 1);
}
當向一個工作隊列提交一個工作時，它並不是在指定的線程裏運行，系統會維護一個Worker Pool, 每個Worker跑在一個單獨的線程裏，每一個CPU都有一個Worker Pool. 當有work需要處理時，就喚醒一個Worker，這樣就減少了系統資源的佔用(原先的實現是每創建一個工作隊列，系統就創建一個線程，由於每個線程都需要有task_struct, pid等資源， 這樣當系統中工作隊列一多的話，資源佔用率就很高了). 由於內核空間是所有進程共享的一塊地址空間，因此在不同進程向工作隊列提交的工作時，用戶其實不用關心我這個工作到底是在哪個進程中處理的，但是這樣的話，如果兩個工作需要同步的話（比如訪問一個共享的資源時），就得仔細考慮了，兩個工作向同一個工作隊列提交時，可能會被同時執行(分別跑在不同的CPU上)， 這樣RACE就產生了， 爲了解決這個問題， 引入了WQ_UNBOUND標誌 和 max_acitve = 1， 這兩個參數指明瞭向這個工作隊列提交一個工作時，這個工作不會綁定在特定的CPU上（如果沒有指明WQ_UNBOUND 標誌的話，在哪個CPU上提交的工作一定會在那個CPU上執行）， max_active指明瞭這個工作隊列後臺有多少個worker線程與之綁定，默認參數爲0,讓系統來指定後臺線程數。