System.Runtime.Remoting.Messaging.CallContext类

MSDN:

CallContext is a specialized collection object similar to a Thread Local Storage for method calls and provides data slots that are unique to each logical thread of execution. The slots are not shared across call contexts on other logical threads. Objects can be added to the CallContext as it travels down and back up the execution code path, and examined by various objects along the path.

本来是很清楚的一个说明。不知道从什么地方看到，从当前线程启动的新线程或异步线程会复制当前线程的CallContext Data。Damn! Is it so?

Code

经过测试发现，没错，我被人忽悠了！

可以看到，子线程和异步线程都无法访问到主线程在CallContext中保存的数据。

另外一点，当使用ASP.NET的时候，虽然线城池里的线程是复用的，但是CallContext并不在一个线程的多次使用中共享。因为CallContext是针对逻辑线程的TLS，线程池中被复用的线程是操作系统中的内核对象而不是托管对象。就像数据库连接池中保存的是非托管资源而不是托管资源。因此，先后执行的两个托管线程可能在底层复用了一个物理线程（内核对象），但并不能共享同一组CallContext数据槽。就像先后new的两个SqlConnection对象可能在底层使用了同一个物理连接，但是托管对象的属性已经被重置。

与此对照的是ThreadStaticAttribute，标记上这个特性的静态字段是往物理线程的TLS中保存数据（根据MSDN的描述猜的。具体没试过），因此如果两个托管线程对象内部使用的是同一个物理线程，则这个字段会复用（在两个线程通过这一字段访问同一个数据槽）。

哎，算了。虽让哥们闲得没事干呢？把ThreadStatic的测试代码也贴出来：

Code

可以看到我的猜测是正确的。ThreadStatic的效果是由JIT实现的。

园子里有个牛人博客的标题是First we try, then we trust.

到我这是：Fist I guess, then I wrong, then I try, then I trust.