ThreadPool类，有两个方法我们没有用到，UnsafeQueueUserWorkItem 和UnsafeRegisterWaitForSingleObject。 为了完全理解这些方法，首先，我们必须回忆 .NET框架中安全策略是怎么运作的。
Windows安全机制是关注资源。操作系统本身允许对文件，用户，注册表键值和任何其它的系统资源设定权限。这种方法对应用系统的用户认证非常有效，但当出现用户对他使用的系统产生不信任的情况时，这就会有些局限性。例如这些程序是从Internet下载的。在这种情况下，一旦用户安装了这个程序，它就可以执行用户权限范围内的任何操作。举个例子，假如用户可以删除他公司内的任何共享文件，任何从Internet下载的程序也都可以这样做。
.NET 提供了应用到程序的安全性策略，而不是用户。这就是说，在用户权限的范围内，我们可以限制任何执行单元（程序集）使用的资源。通过MMC，我们可以根据条件定义一组程序集，然后为每组设置不同的策略，一个典型的例子就是限制从Internet下载的程序访问磁盘的权限。
为了让这个功能运转起来，.NET 框架必须维护一个不同程序集之间的调用栈。假设一个应用没有权限访问磁盘，但是它调用了一个对整个系统都可以访问的类库，当第二个程序集执行一个磁盘的操作时，设置到这个程序集的权限允许这样做，但是权限不会被应用到主叫程序集，.NET不仅要检查当前程序集的权限，而且会检查整个调用栈的权限。这个栈已经被高度优化了，但是它们给两个不同程序集之间的调用增加了额外的负担。
UnsafeQueueUserWorkItem , UnsafeRegisterWaitForSingleObject与 QueueUserWorkItem , RegisterWaitForSingleObject两个方法类似。由于是非安全版本不会维护它们执行函数之间的调用栈，所以非安全版本运行的更快些。但是回调函数将只在当前程序集的安全策略下执行，它就不能应用权限到整个调用栈中的程序集。
我的建议是仅在性能非常重要的、安全已经控制好的极端情况下才用非安全版本。例如，你构建的应用程序不会被其它的程序集调用，或者仅被很明确清楚的程序集使用，那么你可以用非安全版本。如果你开发的类库会被第三方应用程序中使用，那么你就不应该用这些方法，因为它们可能用你的库获取访问系统资源的权限。