A Coder
A Coder

Reputation: 3046

Caching data for lifetime of thread

I'm looking for a way of caching data for the lifetime of a thread. The data doesn't need to be accessible across threads.

In ASP.NET, you can do this using the HttpContext.Current.Items collection.Anything you store in here is retained as long as the thread is alive, and is accessible from any class.

I was wondering if there's a more generic equivalent in the .NET framework (4.0) which isn't tied to HTTP.??

Upvotes: 1

Views: 600

Answers (2)

Jim Mischel
Jim Mischel

Reputation: 134065

The simple answer to your question is to create the cache in the thread proc. For example:

void MyThreadProc(object state)
{
    var myCache = createDataCache();
    // myCache will available throughout the lifetime of the thread
}

As you point out, that's great if your thread is contained in a single method. If you have to call multiple methods, you have to pass that cache to all the methods.

Another alternative is to make the thread proc create an instance of the class that does the actual processing, and have that class own the cache. So your thread proc would look something like:

void MyThreadProc(object state)
{
    var processor = new ThreadDataProcessor();
    processor.DoProcessing();
}

The ThreadDataProcessor constructor would create the cache, and all would be disposed when the thread proc exits. If the ThreadDataProcessor needs access to other data, you'll have to pass references to those structures to the constructor.

Thread local storage works, but you have to be careful when mixing thread local storage and the thread pool. Pool threads can hang around for a very long time (the life of the program), so the thread local storage can accumulate. If you have a lot of thread local data, this could eat up a considerable amount of memory.

All things considered, I'd recommend the second approach above if it's reasonable to do in your application.

Upvotes: 1

A Coder
A Coder

Reputation: 3046

Having created a ThreadLocal<T> object with a default value, you can then use its Value property to get that value or to set it to something else.

You can create as many ThreadLocal<T> objects as you like and they can stored in either instance or static fields.

Thread.AllocateNamedDataSlot does, allocate a named data slot on all threads. However, each thread has its own copy of this named slot and so they can't interfere with each other.

The purpose of thread local storage is to give each thread its own copy of a storage location rather than create storage for one thread in isolation.

Local variables on the thread's stack achieve the latter objective and, as long as there's only a single method call in the thread's execution path, it's really all you need.

However, if there are multiple method calls in the thread's execution path, you have to pass the local variables from method to method which can be awkward in practice. That's really the problem which thread local storage is designed to solve.

Upvotes: 1

Related Questions