C# имеет аналог “ThreadLocal” (для элементов данных) к атрибуту “ThreadStatic”?

Я нашел, что атрибут "ThreadStatic" недавно чрезвычайно полезен, но заставляет меня теперь хотеть атрибут типа "ThreadLocal", который позволяет мне иметь нестатические элементы данных на основе на поток.

Теперь я знаю, что это имело бы некоторые нетривиальные последствия, но:

Такая вещь уже существует встроенная в C#/.net? или так как кажется до сих пор, что ответ на это не (для .NET <4.0), есть ли там наиболее часто используемая реализация?

Я могу думать о разумном способе реализовать его сам, но просто использовал бы что-то, что уже существовало, если это было доступно.

Соломенный пример Человека, который реализовал бы то, что я ищу, если он уже не существует:

class Foo
{
    [ThreadStatic] 
    static Dictionary<Object,int> threadLocalValues = new Dictionary<Object,int>();
    int defaultValue = 0;

    int ThreadLocalMember
    {
         get 
         { 
              int value = defaultValue;
              if( ! threadLocalValues.TryGetValue(this, out value) )
              {
                 threadLocalValues[this] = value;
              }
              return value; 
         }
         set { threadLocalValues[this] = value; }
    }
}

Простите любое незнание C#. Я - разработчик C++, который только недавно входил в более интересные функции C# и .NET

Я ограничен .net 3.0, и возможно 3.5 (проект скоро / перемещение к 3,5).

Определенный пример использования является списками обратных вызовов, которые являются конкретным потоком (использование мнимого [ThreadLocal] атрибут) а-ля:

class NonSingletonSharedThing
{
     [ThreadLocal] List<Callback> callbacks;

     public void ThreadLocalRegisterCallback( Callback somecallback )
     {    
         callbacks.Add(somecallback);    
     }

     public void ThreadLocalDoCallbacks();
     {    
         foreach( var callback in callbacks )  
            callback.invoke();  
     }
}
22
задан 15 revs 4 February 2010 в 21:33
поделиться

8 ответов

Введите .NET 4.0!

Если вы застряли в 3.5 (или раньше), есть Некоторые функции Вы должны посмотреть, как AllocatedataTaslot , который должен делать то, что вы хотите.

22
ответ дан 29 November 2019 в 04:50
поделиться

Если вы хотите хранить уникальные данные на основании на поток, вы можете использовать Thread.SetData. Обязательно ознакомьтесь с плюсами и минусами http://msdn.microsoft.com/en-us/library/6sby1byh.aspx Как это имеет последствия для производительности.

4
ответ дан 29 November 2019 в 04:50
поделиться

Вы должны подумать об этом дважды. Вы по сути создаете утечку памяти. Каждый объект , созданный нити, остается ссылается, и не может быть собранным мусором. Пока нить не заканчивается.

5
ответ дан 29 November 2019 в 04:50
поделиться

Я не уверен, что вы нередите свои темы в первую очередь, но есть способы дать каждому потоку свою поток-локальное хранилище, без использования Hackish Wearabounds, как код, который вы размещены в вашем вопросе.

public void SpawnSomeThreads(int threads)
{
    for (int i = 0; i < threads; i++)
    {
        Thread t = new Thread(WorkerThread);

        WorkerThreadContext context = new WorkerThreadContext
        {
            // whatever data the thread needs passed into it
        };

        t.Start(context);
    }
}

private class WorkerThreadContext
{
    public string Data { get; set; }
    public int OtherData { get; set; }
}

private void WorkerThread(object parameter)
{
    WorkerThreadContext context = (WorkerThreadContext) parameter;

    // do work here
}

Это, очевидно, игнорирует в ожидании потоков, чтобы завершить свою работу, убедившись, что доступ к любому общему состоянию - это безрезультатно на всех рабочих потоках, но вы получаете идею.

0
ответ дан 29 November 2019 в 04:50
поделиться

Хотя я все еще не уверен, когда ваш вариант использования будет иметь смысл (см. Мой комментарий к самому вопросу), я хотел бы предложить рабочий пример это, на мой взгляд, более читабельно, чем локальное хранилище потока (статическое или экземплярное). В примере используется .NET 3.5:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.Linq;

namespace SimulatedThreadLocal
{
    public sealed class Notifier
    {
        public void Register(Func<string> callback)
        {
            var id = Thread.CurrentThread.ManagedThreadId;
            lock (this._callbacks)
            {
                List<Func<string>> list;
                if (!this._callbacks.TryGetValue(id, out list))
                {
                    this._callbacks[id] = list = new List<Func<string>>();
                }
                list.Add(callback);
            }
        }

        public void Execute()
        {
            var id = Thread.CurrentThread.ManagedThreadId;
            IEnumerable<Func<string>> threadCallbacks;
            string status;
            lock (this._callbacks)
            {
                status = string.Format("Notifier has callbacks from {0} threads, total {1} callbacks{2}Executing on thread {3}",
                    this._callbacks.Count,
                    this._callbacks.SelectMany(d => d.Value).Count(),
                    Environment.NewLine,
                    Thread.CurrentThread.ManagedThreadId);
                threadCallbacks = this._callbacks[id]; // we can use the original collection, as only this thread can add to it and we're not going to be adding right now
            }

            var b = new StringBuilder();
            foreach (var callback in threadCallbacks)
            {
                b.AppendLine(callback());
            }

            Console.ForegroundColor = ConsoleColor.DarkYellow;
            Console.WriteLine(status);
            Console.ForegroundColor = ConsoleColor.Green;
            Console.WriteLine(b.ToString());
        }

        private readonly Dictionary<int, List<Func<string>>> _callbacks = new Dictionary<int, List<Func<string>>>();
    }

    public static class Program
    {
        public static void Main(string[] args)
        {
            try
            {
                var notifier = new Notifier();
                var syncMainThread = new ManualResetEvent(false);
                var syncWorkerThread = new ManualResetEvent(false);

                ThreadPool.QueueUserWorkItem(delegate // will create closure to see notifier and sync* events
                {
                    notifier.Register(() => string.Format("Worker thread callback A (thread ID = {0})", Thread.CurrentThread.ManagedThreadId));
                    syncMainThread.Set();
                    syncWorkerThread.WaitOne(); // wait for main thread to execute notifications in its context

                    syncWorkerThread.Reset();
                    notifier.Execute();
                    notifier.Register(() => string.Format("Worker thread callback B (thread ID = {0})", Thread.CurrentThread.ManagedThreadId));
                    syncMainThread.Set();
                    syncWorkerThread.WaitOne(); // wait for main thread to execute notifications in its context

                    syncWorkerThread.Reset();
                    notifier.Execute();
                    syncMainThread.Set();
                });

                notifier.Register(() => string.Format("Main thread callback A (thread ID = {0})", Thread.CurrentThread.ManagedThreadId));
                syncMainThread.WaitOne(); // wait for worker thread to add its notification

                syncMainThread.Reset();
                notifier.Execute();
                syncWorkerThread.Set();
                syncMainThread.WaitOne(); // wait for worker thread to execute notifications in its context

                syncMainThread.Reset();
                notifier.Register(() => string.Format("Main thread callback B (thread ID = {0})", Thread.CurrentThread.ManagedThreadId));
                notifier.Execute();
                syncWorkerThread.Set();
                syncMainThread.WaitOne(); // wait for worker thread to execute notifications in its context

                syncMainThread.Reset();
            }
            finally
            {
                Console.ResetColor();
            }
        }
    }
}

Когда вы скомпилируете и запустите вышеуказанную программу, вы должны получить следующий результат: alt text http://img695.imageshack.us/img695/991 /threadlocal.png

Исходя из вашего варианта использования, я предполагаю, что это именно то, чего вы пытаетесь достичь. В примере сначала добавляются два обратных вызова из двух разных контекстов, основного и рабочего потоков. Затем в примере сначала запускается уведомление из основного, а затем из рабочих потоков.Выполняемые обратные вызовы эффективно фильтруются по идентификатору текущего потока. Чтобы показать, что все работает, как ожидалось, в примере добавляются еще два обратных вызова (всего 4) и снова запускается уведомление из контекста основного и рабочего потоков.

Обратите внимание, что класс Notifier - это обычный экземпляр, который может иметь состояние, несколько экземпляров и т. Д. (Опять же, согласно варианту использования вашего вопроса). В этом примере не используются статические, статические или локальные потоки.

Буду признателен, если вы посмотрите код и дадите мне знать, если я неправильно понял, чего вы пытаетесь достичь, или если подобная техника удовлетворит ваши потребности.

1
ответ дан 29 November 2019 в 04:50
поделиться

Примите во внимание:

Вместо того, чтобы пытаться присвоить каждой переменной-члену в объекте значение, зависящее от потока, дайте каждому потоку его собственный экземпляр объекта. - передать объект в threadstart как состояние или сделать метод threadstart членом объекта, которым поток будет «владеть», и создать новый экземпляр для каждого порождаемого вами потока.

Изменить (в ответ на замечание Катскуля. Вот пример инкапсуляции структуры


public class TheStructWorkerClass
{
  private StructData TheStruct;
  public TheStructWorkerClass(StructData yourStruct)
  {
    this.TheStruct = yourStruct;
  }

  public void ExecuteAsync()
  {
    System.Threading.ThreadPool.QueueUserWorkItem(this.TheWorkerMethod);
  }
  private void TheWorkerMethod(object state)
  {
     // your processing logic here
     // you can access your structure as this.TheStruct;
     // only this thread has access to the struct (as long as you don't pass the struct
     // to another worker class)
  }
}

// now hte code that launches the async process does this:
  var worker = new TheStructWorkerClass(yourStruct);
  worker.ExecuteAsync();

Теперь вот вариант 2 (передать структуру как состояние)


 {
 // (from somewhere in your existing code
    System.Threading.Threadpool.QueueUserWorkItem(this.TheWorker, myStruct);
 } 

  private void TheWorker(object state)
  { 
    StructData yourStruct = (StructData)state;
    // now do stuff with your struct
    // works fine as long as you never pass the same instance of your struct to 2 different threads.
  }

4
ответ дан 29 November 2019 в 04:50
поделиться

В итоге я реализовал и протестировал версию того, что предложил изначально:

public class ThreadLocal<T>
{
    [ThreadStatic] private static Dictionary<object, T> _lookupTable;

    private Dictionary<object, T> LookupTable
    {
        get
        {
            if ( _lookupTable == null)
                _lookupTable = new Dictionary<object, T>();

            return _lookupTable;
        }
    }


    private object key = new object(); //lazy hash key creation handles replacement
    private T originalValue;

    public ThreadLocal( T value )
    {
        originalValue = value;
    }

    ~ThreadLocal()
    {
        LookupTable.Remove(key);
    }

    public void Set( T value)
    {
        LookupTable[key] = value;
    }

    public T Get()
    {
        T returnValue = default(T);
        if (!LookupTable.TryGetValue(key, out returnValue))
            Set(originalValue);

        return returnValue;
    }
}
3
ответ дан 29 November 2019 в 04:50
поделиться

Хотя опубликованное решение выглядит элегантно, оно пропускает объекты. Финализатор - LookupTable.Remove (ключ) - запускается только в контексте потока сборщика мусора, поэтому он, скорее всего, только создает дополнительный мусор при создании другой таблицы поиска.

Вам необходимо удалить объект из таблицы поиска каждого потока, который обращался к ThreadLocal. Единственный элегантный способ решить эту проблему - использовать словарь со слабыми ключами - структуру данных, которая странным образом отсутствует в C #.

0
ответ дан 29 November 2019 в 04:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: