什么时候应该使用ThreadLocal而不是Thread.SetData / Thread.GetData?

时间:2011-11-11 17:37:21

标签: c# multithreading c#-4.0

在.net 4.0之前,我在System.Threading.Thread中使用命名数据槽实现了一个解决方案。现在,在.net 4.0中,有ThreadLocal的想法。 ThreadLocal用法如何与命名数据槽相比? ThreadLocal值是否由子线程继承?是否认为ThreadLocal是使用命名数据槽的简化版本?下面是使用命名数据槽的一些内容的示例。这可以通过使用ThreadLocal来简化,它是否会保留与命名数据槽相同的属性?

    public static void SetSliceName(string slice)
    {
        System.Threading.Thread.SetData(System.Threading.Thread.GetNamedDataSlot(SliceVariable), slice);
    }

    public static string GetSliceName(bool errorIfNotFound)
    {
        var slice = System.Threading.Thread.GetData(System.Threading.Thread.GetNamedDataSlot(SliceVariable)) as string;
        if (errorIfNotFound && string.IsNullOrEmpty(slice)) {throw new ConfigurationErrorsException("Server slice name not configured.");}
        return slice;
    }

1 个答案:

答案 0 :(得分:2)

看起来新的ThreadLocal类是Thread.GetData / SetData API的类型安全等价物。

无论机制如何,线程本地存储都不应该被“子线程”继承。根据定义,TLS是每个单独线程的本地。

请注意,[ThreadStatic]属性自.NET 2.0以来一直在提供TLS。