.Net4.0并行库介绍——线程专有存储

在.Net 4.0的Thread里，新增了线程局部变量（ThreadLocal）类，可以很方便的实现线程专有存储。

应用场景

线程专有存储应被用于这样的多线程应用：它们经常访问那些逻辑上是全局的、而物理上是专有于每个线程的对象。首先我们看如下这样一个例子

    string errorMessage;

    void Process()
    {
        bool ret = Run();
        if (!ret && needDebug)
        {
            Console.WriteLine(errorMessage);
        }
    }

    bool Run()
    {
        try
        {
            //…-- do something
            return true;
        }
        catch (Exception e)
        {
            errorMessage = e.Message;
            return false;
        }
    }

这个函数中，Process为主体函数，当它调用Run函数失败后，为调式方便，打出Run函数的错误信息。错误信息采用成员变量errorMessage存放，为了减少Run函数的参数。

这种通过成员变量errorMessage在函数间传递信息的方式在单线程程序中可以很好的工作，但是在多线程应用时却往往会发生一些微妙的问题：当两个线程同时执行Run函数时，先执行的会被后执行的线程覆盖，导致输出了错误的后执行的线程的调试信息。发生类似数据库的脏读错误。

解决方案：

最直接的解决方案有两种：

加锁：在Process中加锁，保证没有两个线程同时访问errorMessage

修改Run函数为bool Run(out string errorMessage)的形式，不通过errorMessage共享数据，使其支持并发操作。

这两种方式都是有效的，但都有一些不足：加锁时获取和释放互斥体有一个不小的开销，当共享的数据较多时修改Run函数会导致Run函数变得很难看，并且可能会由于改动较大而导致大规模重构。

针对上述两种方式的不足，人们提出了线程专有存储的解决方案，使用ThreadLocal类的解决方案如下：

    ThreadLocal<string> errorMessage = new ThreadLocal<string> ();

    void Process()
    {
        bool ret = Run();
        if (!ret && needDebug)
        {
            Console.WriteLine(errorMessage);
        }
    }

    bool Run()
    {
        try
        {
            …- do something
            return true;
        }
        catch (Exception e)
        {
            errorMessage.Value=e.Message;
            return false;
        }
    }

ThreadLocal类在每个线程下都分配一个独立实例副本，每个线程都只访问到自己的实例，不会影响其它线程，从而解决读脏数据的问题。

ThreadLocal类也不是什么新概念，在C++、Java等语言的线程库中都有相关实现，一些语言编译器实现（如IBM XL FORTRAN）中甚至在语言的层次提供了直接的支持。其实实现的思路很简单：在ThreadLocal类中有一个哈希表，根据线程ID为key用于存储每一个线程的变量的副本。由于现在没啥相关资料，并且也是beta版的，我也懒得对.Net中的具体实现和性能进一步分析。

和上面的两种方式相比，线程专有存储有如下好处：

1. 效率：线程专有存储可实现成无需对线程专有数据进行锁定。例如，通过将errno放入线程专有存储中，每个线程都可以可靠地设置和测试该线程中的方法的完成状态，而无需使用复杂的同步协议。这排除了线程中共享数据的锁定开销，比起获取和释放互斥体要更为迅捷。
2. 易于使用：对于应用程序员来说，线程专有存储使用起来很简单，因为系统开发者可以通过数据抽象或宏来使线程专有存储的使用在源码级完全透明化。

但也存在如下缺点：

1. 它鼓励了（线程安全的）全局变量的使用：许多应用不要求多个线程通过公用访问点来访问线程专有的数据。如果是这样，数据的存储应使只有拥有该数据的线程可对它进行访问。
2. 它隐藏了系统的结构：线程专有存储的使用隐藏了应用中的对象之间的关系，可能会导致应用更难被理解。

适用性

应用有以下特性时可使用线程专有存储：

1. 应用最初的编写假定了单线程控制，并正在被移植到多线程环境，而又不能改变现有API
2. 应用含有多个占先式线程控制，可以任意的调度顺序并发执行；
3. 每个线程控制调用一系列方法，这些方法共享只对该线程来说是公用的数据；
4. 在每个线程中被对象共享的数据必须通过一个全局可见的访问点来访问；
5. 访问点"逻辑地"与其他线程共享，但在"物理上" 对于每个线程却是唯一的；
6. 数据在方法间隐式地传递，而不是经由参数显式地传递。

理解上面描述的特性对于使用（或不使用）线程专有存储模式来说是至关紧要的。例如，UNIX errno变量是一个数据例子：（1）逻辑上全局，但是物理上线程专有，以及（2）在方法间隐式地传递。

当应用有以下特性时，不要使用线程专有存储模式：

1. 多个线程为单个任务协同工作，该任务需要并发访问共享数据。
   例如，多线程应用可以对在内存中的数据库并发地进行读写。在这样的情况下，线程必须共享不是线程专有的记录和表。如果使用线程专有存储来存储此数据库，线程就不能共享这些数据。因而，对数据库记录的访问必须通过同步原语（例如，互斥体）来控制，以使线程能在共享数据上协作。
2. 维护物理和逻辑上都分离的数据要更为直观和高效。
   例如，通过将数据作为参数显式地传递给所有方法，有可能使线程访问仅在每个线程中可见的数据。在这样的情况下，线程专有存储模式有可能是不必要的。