Я нашел, что атрибут "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();
}
}
Если вы застряли в 3.5 (или раньше), есть Некоторые функции Вы должны посмотреть, как AllocatedataTaslot
, который должен делать то, что вы хотите.
Если вы хотите хранить уникальные данные на основании на поток, вы можете использовать Thread.SetData. Обязательно ознакомьтесь с плюсами и минусами http://msdn.microsoft.com/en-us/library/6sby1byh.aspx Как это имеет последствия для производительности.
Вы должны подумать об этом дважды. Вы по сути создаете утечку памяти. Каждый объект , созданный нити, остается ссылается, и не может быть собранным мусором. Пока нить не заканчивается.
Я не уверен, что вы нередите свои темы в первую очередь, но есть способы дать каждому потоку свою поток-локальное хранилище, без использования 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
}
Это, очевидно, игнорирует в ожидании потоков, чтобы завершить свою работу, убедившись, что доступ к любому общему состоянию - это безрезультатно на всех рабочих потоках, но вы получаете идею.
Хотя я все еще не уверен, когда ваш вариант использования будет иметь смысл (см. Мой комментарий к самому вопросу), я хотел бы предложить рабочий пример это, на мой взгляд, более читабельно, чем локальное хранилище потока (статическое или экземплярное). В примере используется .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 - это обычный экземпляр, который может иметь состояние, несколько экземпляров и т. Д. (Опять же, согласно варианту использования вашего вопроса). В этом примере не используются статические, статические или локальные потоки.
Буду признателен, если вы посмотрите код и дадите мне знать, если я неправильно понял, чего вы пытаетесь достичь, или если подобная техника удовлетворит ваши потребности.
Примите во внимание:
Вместо того, чтобы пытаться присвоить каждой переменной-члену в объекте значение, зависящее от потока, дайте каждому потоку его собственный экземпляр объекта. - передать объект в 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.
}
В итоге я реализовал и протестировал версию того, что предложил изначально:
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;
}
}
Хотя опубликованное решение выглядит элегантно, оно пропускает объекты. Финализатор - LookupTable.Remove (ключ) - запускается только в контексте потока сборщика мусора, поэтому он, скорее всего, только создает дополнительный мусор при создании другой таблицы поиска.
Вам необходимо удалить объект из таблицы поиска каждого потока, который обращался к ThreadLocal. Единственный элегантный способ решить эту проблему - использовать словарь со слабыми ключами - структуру данных, которая странным образом отсутствует в C #.