4

A friend asked me which would be better ThreadStatic or ThreadLocal. Checking the doc I told him ThreadLocal looks more convenient, is available since .NET 4.0, but I don't understand why use any of them over creating object instance for a thread. Their purpose is to store "thread-local-data", so you can call methods less clumsily and avoid locking in some instances. When I wanted such thread-local-data I always was creating something like:

    class ThreadHandler
    {
        SomeClass A;

        public ThreadHandler(SomeClass A)
        {
            this.A = A;
        }

        public void Worker()
        {
        }
    }

If I want just fire and forget thread it would be new Thread(new ThreadHandler(new SomeClass()).TheWorkerMethod).Start(), if I want to track threads it can be added to collection, if I want to track data ThreadHandler can be added to collection, if I want to handle both I can make Thread property for ThreadHandler and put ThreadHandler to collection, I want threadpool it's QueueUserWorkItem instead of new Thread(). It's short and simple if scope is simple, but easily extensible if scope gets wider.

When I'm trying to google why use ThreadLocal over an object instance all my searches end up with explanation how ThreadLocal is much greater than ThreadStatic, which in my eyes look like people explaining that they had this clumsy screwdriver, but now toolbox has heavy monkey-wrench which is much more convenient for hammering nails. Whilst toolbox had a hammer to begin with.

I understand I'm missing something, because if ThreadStatic/ThreadLocal had no advantage they just wouldn't exist. Can somebody please point out at least one significant advantage of ThreadLocal over creating an object instance for a thread?

UPD: Looks like a double of this, I think when I was googling "java" keyword was throwing me off. So there's at least one advantage - ThreadLocal is more natural to use with Task Parallel Library.

Community
  • 1
  • 1
Djust
  • 43
  • 5

4 Answers4

3

I don't get advantage of ThreadLocal over creating an instance of object for a thread.

You're right, when you have control over the threads being created, and how they're used, it's very handy to just wrap the whole thread in a helper class, and have it get 'thread local' data from there.

The problem is that, especially in institutionally large projects, you don't always have this kind of control. You may start up a thread, and call some code, and that one thread may wind its way through calls in millions of lines of code scattered between 10 projects owned by 3 internal teams and one external contractor team. Good luck plumbing some of those parameters everywhere.

Thread-local storage lets those guys interact without requiring that they have explicit references to the object that represents that thread's context.

A related problem I had was associating data to some thread and every child thread created by that thread (since my large projects create their own threads, and so thread-local doesn't work anymore), see this question I had: Is there any programmable data that is automatically inherited by children Thread objects?

At the end of the day, it's often lazy programming, but sometimes you find situations where you just need it.

Community
  • 1
  • 1
antiduh
  • 11,853
  • 4
  • 43
  • 66
2

ThreadLocal<T> works like a Dictionary<Thread, T>. The problem with a dictionary is that instances belonging to killed or dead threads stay around forever - they don't get garbage collected, because they are referenced by the dictionary. Using ThreadLocal will ensure that, when a thread dies, the instances referenced by that thread are eligible for GC.

Plus, it's a much nicer interface than having to manually deal with a Dictionary<Thread, T>. It Just Works.

thecoop
  • 45,220
  • 19
  • 132
  • 189
  • I understand advantage of ThreadLocal over dictionary with thread key. I don't get advantage of ThreadLocal over creating an instance of object for a thread. – Djust Jul 10 '14 at 00:31
  • 1
    It's a useful abstraction. The same argument can be used for using `List`, or `HashSet` - why use those when you can just use an array? It's not required, but it packages up common functionality in a useful way that has been well tested. In the end, the less code you need to write the better, because the less chance there is for bugs to creep in. – thecoop Jul 10 '14 at 09:17
0

ThreadLocal has 2 benefits over ThreadStatic attribute approach, you can avoid to define class-field and it has built in lazy loading feature. your manual collection approach requires locking mechanism, if you look ThreadLocal's source code, you see its optimized to this specific case.

TakeMeAsAGuest
  • 957
  • 6
  • 11
0

ThreadLocal can get benfits when T type object new and gc frequenctly. And it's thread safe.

Feiyu Zhou
  • 4,344
  • 32
  • 36