c# - 是否有任何由子线程对象自动继承的可编程数据？

Question

我有一个想法来解决在 .Net 中枚举托管线程和跟踪线程祖先(哪个线程创建了哪个其他线程)的问题。

如果可以使用程序员创建的对象来标记 Thread 对象，该对象会在创建子线程时自动复制到子线程，则可以使用该标记来跟踪新线程的创建时间、创建者等。灵感来自 unix，其中，当一个进程被 fork 时，它继承了打开的文件句柄等。如果有一些数据是 1) 线程本地的或绑定(bind)到一个 Thread 对象和 2) 自动复制到新的线程和 3) 是可修改的，这将是一个好的开始。

我猜我们将不得不使用反射来访问一些启动链的 Thread 对象的成员，因为我在线程中看到的大部分可能有用的东西都被锁定了，但这是一个开始。不过，我不确定这种方法有多明智。

编辑:
我想我会更好地解释我的用例，因为我认为没有人理解。

我知道显式跟踪线程，我以前在我拥有的代码中广泛使用过。那不是问题。

基本上，我正在尝试实现一个“线程组上下文”，这与 .Net 具有应用域上下文、远程处理上下文的方式非常相似 [1]和程序集线程组合本地上下文 [2] .

对于从公共(public)线程产生的给定线程组，我想将信息与该分组相关联。虽然我知道 .Net 没有这个概念(否则我不会有问题!)，它并没有改变这样一个事实，即 .Net 中的每个托管线程都是由一个且只有一个其他托管线程创建的，因此，可以绘制成树状结构。

因此，我试图解决的问题是:我有一个 API，它有一个上下文对象。这个 API 调用一个大型的外部代码库来做真正的工作，并且从它的创建线程开始。该外部不会显式获取 API 上下文对象的副本，但是它需要一个副本才能调用 API。由于它没有对 API 上下文对象的引用，因此无法进行这些调用。按照今天的情况，外部库确实需要进行调用，为此它会在单个静态字段中查找当前上下文对象，这意味着每个 AppDomain 只能有一个我的 API 实例。我想解决这个问题。

这个外部库部分是我无法控制的，我的 API 和外部库之间的接口(interface)没有明确传递上下文对象。到目前为止，当外部库需要调用 API 时，它会查看我的 API 中的静态字段以获取对上下文对象的引用。

问题是最终的可执行文件每个 AppDomain 只能有一个我的 API session 实例，因为我们使用静态字段将上下文对象传递给外部库(主力)代码。

一种选择是在我的 API 中创建一个 GetContextObject() 方法。当 API 生成线程以运行外部库代码时，它会在共享静态字典中记住该线程。当外部库代码调用 GetContextObject() 时，它将查找它正在运行的线程并返回该线程的正确上下文对象。

如果外部库代码从来没有创建过自己的线程，那么我就没有问题，我总是有一个 100% 正确的线程到上下文的映射。但是，外部库确实创建了自己的线程，并且在我的 API 不知道的情况下这样做了。当 API 收到来自这些线程的调用时，它不知道要放弃哪个上下文对象，并且必须猜测 - 如果只有一个上下文对象注册，则使用该对象，否则，它会抛出异常表示不能告诉你。

如果我可以将数据标记到由该父线程创建的线程继承的线程对象，那么我就可以实现这个跟踪系统。

此外，外部库不使用线程池。

基本上，我的选择是:

1)重新设计我的API和外部库之间的接口(interface)来传入上下文对象，重新设计外部库以正确传递这个上下文对象。涉及穿越约 100 万个 LOC。

1a) 禁止外部库直接使用 Thread 对象，而是要求它们使用我自己的 MyApiThread 对象，该对象在创建时会添加到我的自定义跟踪机制中。与选项 #1 相比，需要在外部库中更改更少的代码，但仍需要大量返工。

2) 强制我的 API 的使用者在新的 AppDomain 中启动每个 API session ，以便我可以将我的上下文对象存储在静态字段中(这是今天的“解决方案”)。 AppDomains 涉及大量开销，我不希望将其强加给我的用户。

3)找到一种跟踪线程祖先的方法，以便能够根据调用线程将正确的上下文对象返回给从外部库调用的代码。这是这篇文章的主题。

对于那些说 Windows 没有子-父线程概念的人来说，你是偏离基础的——这是无关紧要的。 DotNet 不是一个只支持 Windows 的系统，它的设计本身就是将它与运行它的机器和操作系统隔离开来，这就是为什么 .Net 以 Mono 的形式存在于 Linux、Solaris、FreeBSD 中。此外，Java 确实有我需要的线程祖先的概念，并且 Java 是在 Windows 上实现的，因此这是一个非常可能和合理的概念。虽然我意识到 .Net api 有某种特定于 Microsoft 的倾向，但要意识到，在很大程度上，.Net 和 Windows 是独立的。

Answer 1

事实上，我会将我的评论作为一个答案并指向您 Jeffrey Richter .

CallContext 类使您能够为“逻辑执行路径”存储数据，该路径可以跨线程和 AppDomains。