views:

321

answers:

2

I discovered 'ThreadStaticAttribute', and I have a lot of questions about it: all my previous thread dependent static informations, were implemented as a static dictionary wich TKey is Thread, and when I wanted to access it, I used Thread.CurrentThread and that works. But this requires mantainance, because if a thread dies, I have to delete the corresponding entry from the dictionary. And I also need to consider thread-safety, and a lot of other matters.

By using ThreadStaticAttribute, all these matters seems to be solved, but I need to be sure of it. My questions are: do I need to delete the instance hold by 'ThreadStaticAttribute' marked fields, somehow, before the thread dies?? Where is the information of that field hold?? It is in the instance of Thread object, or something like that, so that when it is not used anymore, garbage collector automatically discards it? Are there performance penalties? What ones? Is it faster than using a Keyed collection like I was doing?

Please, I need clarification on how 'ThreadStaticAttribute' work.

Thanks.

+3  A: 

No you do not need to delete instances of values help in a field which is tagged with ThreadStatic. The garbage collector will automatically pick them up when both the thread and the object are no longer reachable by rooted objects.

The only exception here is if the value implements IDisposable and you want to actively dispose of it. In general this is a hard problem to solve for a number of reasons. It's much simpler to not have values which implement IDisposable and are in a ThreadStatic field.

As to where this field is actually stored, it's somewhat irrelevant. All you need to be concerned about is that it will behave like any other object in .Net. The only two behavior differences are

  1. The field will reference a difference value per accessing thread.
  2. The initializer for the field will only be run once (in practice, it's a bad idea to have any).
JaredPar
+2  A: 

Marking a static member variable as [ThreadStatic] tells the compiler to allocate it in the thread's memory area (eg. where the thread's stack is allocated) rather than in the global memory area. Thus, each thread will have its own copy (which are guaranteed to be initialized to the default value for that type, eg. null, 0, false, etc; do not use in-line initializers as they will only initialize it for one thread).

So, when the thread goes away, so does its memory area, releasing the reference. Of course if it's something that needs more immediate disposal (open file streams, etc) instead of waiting for background garbage collection, you might want to make sure you do that before the thread exits.

There could be a limit to the amount of [ThreadStatic] space available, but it should be sufficient for sane uses. It should be somewhat faster than accessing a keyed collection (and more easily thread-safe), and I think it's comparable to accessing a normal static variable.

Rob Parker
The compiler quite literally does nothing for the `ThreadStatic` attribute. It is entirely handled by the CLR
JaredPar
Okay, but taking "compiler" in a metaphorical sense rather than strictly literal sense, you get the idea as far as how to use the attribute.
Rob Parker