ThreadPool類，有兩個方法我們沒有用到，UnsafeQueueUserWorkItem 和UnsafeRegisterWaitForSingleObject。 為了完全理解這些方法，首先，我們必須回憶 .NET框架中安全策略是怎麽運作的。

Windows安全機制是關註資源。操作系統本身允許對文件，用戶，註冊表鍵值和任何其它的系統資源設定權限。這種方法對應用系統的用戶認證非常有效，但當出現用戶對他使用的系統產生不信任的情況時，這就會有些局限性。例如這些程序是從Internet下載的。在這種情況下，一旦用戶安裝了這個程序，它就可以執行用戶權限範圍內的任何操作。舉個例子，假如用戶可以刪除他公司內的任何共享文件，任何從Internet下載的程序也都可以這樣做。

.NET 提供了應用到程序的安全性策略，而不是用戶。這就是說，在用戶權限的範圍內，我們可以限制任何執行單元（程序集）使用的資源。通過MMC，我們可以根據條件定義一組程序集，然後為每組設置不同的策略，一個典型的例子就是限制從Internet下載的程序訪問磁盤的權限。

為了讓這個功能運轉起來，.NET 框架必須維護一個不同程序集之間的調用棧。假設一個應用沒有權限訪問磁盤，但是它調用了一個對整個系統都可以訪問的類庫，當第二個程序集執行一個磁盤的操作時，設置到這個程序集的權限允許這樣做，但是權限不會被應用到主叫程序集，.NET不僅要檢查當前程序集的權限，而且會檢查整個調用棧的權限。這個棧已經被高度優化了，但是它們給兩個不同程序集之間的調用增加了額外的負擔。

UnsafeQueueUserWorkItem , UnsafeRegisterWaitForSingleObject與 QueueUserWorkItem , RegisterWaitForSingleObject兩個方法類似。由於是非安全版本不會維護它們執行函數之間的調用棧，所以非安全版本運行的更快些。但是回調函數將只在當前程序集的安全策略下執行，它就不能應用權限到整個調用棧中的程序集。

我的建議是僅在性能非常重要的、安全已經控制好的極端情況下才用非安全版本。例如，你構建的應用程序不會被其它的程序集調用，或者僅被很明確清楚的程序集使用，那麽你可以用非安全版本。如果你開發的類庫會被第三方應用程序中使用，那麽你就不應該用這些方法，因為它們可能用你的庫獲取訪問系統資源的權限。

[.net 多線程]ThreadPool的安全機制