.net - 使用 .NET ThreadPool 线程时使用 CallContext.Logical[set/get]Data 是否安全？

Question

我知道使用这些方法设置的 LogicalCallContext 会流向新线程，如果您使用像 ThreadPool.QueueUserWorkItem。问题是，当线程池重新使用具有此对象的线程时，逻辑调用上下文是否会重置？或者我最终会得到不属于我的状态？

提到的几个:

从我从 .net 源代码中可以看出，每当您将新任务排队到线程池时，整个执行上下文都会被克隆。这个上下文也包括安全相关的东西，所以我认为如果不重置上下文，这将是一个主要的禁忌。

在测试应用程序中，它似乎工作正常，即使我在完成后将上下文中的状态设置为虚拟值，只是为了使其更有可能在重新使用时出现错误状态.

我没有使用任何异步编程、windows 窗体/WPF 或类似的东西。只是简单的 .NET api 调用(并且没有以“开始...”开头)

我知道仅仅使用线程本地存储是行不通的，因为当线程切换时它不会被清除。

谢谢

Answer 1

2020 年编辑:在最近对一个大型遗留项目(基本上是一个 Web 服务器)采用此方法后，它没有任何问题。

不能说我推荐它，但如果它使您免于对大型代码库进行不可能的重构，从而“携带”状态，那么它可能值得一试。

我或多或少只是用汉斯的回答来回答。

You are using this feature off-label, LCC is a Remoting detail. It works because the SecurityContext needs to flow to the tp thread. A CAS feature, deprecated at .NET 4.0. You can't get a warranty here.

似乎来自 MS 的一些技术也使用 CallContext，例如 Entity Framework 6，但具体细节尚不清楚(它们是否会产生威胁，是否使用异步编程)。

所以，答案应该是否定的，以这种方式使用它是不安全的。