Когда следует использовать ThreadLocal вместо Thread.SetData / Thread.GetData? - PullRequest
4 голосов
/ 11 ноября 2011

До .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 Ответ

2 голосов
/ 11 ноября 2011

Похоже, что новый класс ThreadLocal является безопасным по типу эквивалентом API Thread.GetData / SetData.

Локальное хранилище потоков никогда не должно наследоваться «дочерними потоками» независимо от механизма. TLS по определению является локальным для каждого отдельного потока.

Обратите внимание, что атрибут [ThreadStatic] предоставляет TLS начиная с .NET 2.0.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...