Today I thought to tell you something on one of the most complex part of .NET Framework I.e. Threading. I was discussing some of the issues with one of our team member on threading today;
from taking inspiration on that conversion; here are the facts of .NET Threading....
.NET Thread object is "ACTUALLY" not created by .NET; its Operating level thread we are just getting a decorated version of that thread. When we talk about Thread; we must remember the thread pool. The thread pool is just a wrapper class of OS Level thread pool which is optimized for faster allocating/deal locating the memory and thread data. While taking back used thread from user application the same class is also responsible to cleared off the data. This is the internal operation; as a user we don't need to care about it.
The second fact is: some of the blogs (NOT MSDN) mentioned that when you write the code something like:
Thread t = new Thread(DoSomething);
Its actually not a part of ThreadPool and its creating new thread; which may be right in a way. But this is not the fully truth. If we believe on the blog for an instance; we may not get duplicate thread ever. Now here i am no going in depth of Allocation thread memory, execution etc. but let me tell you one point; even if you write above statement in .NET; it serves the thread object from Pool only. I know you will not believe this fact.
I have created an example which works on above assumption have a look once.. its interesting to see. I am creating thread using above code and some times i am getting new thread (Displayed in White Font) and some times i get duplicate thread (Displayed in Yellow Font). It proves that internally .NET is keeping a pool of thread.
The second point; In example;I have also set some data on fresh thread each time. Which I am trying to recover when I get the duplicate thread object. And look at the result; The Thread Slot is still there; but .NET erased the data.
In summery you can say that:
1. Thread object never created/destroyed from .NET Managed Env. user always gets the thread object from pool only.
2. The data you associates with thread (In terms of Thread Slots and ThreadStatic variables) are not persisted on the thread when .NET collects the unused thread for pooling.
When Thread Slots are getting cleared off; there is no question to persist the value of ThreadStatic variables.
Now talking about WCF execution; like this example when you open the WCF Service Channel/Port; it takes one of the available thread from same pool and starts the execution of the code using the thread. You can never get the older data associated with associated with thread earlier. So its perfectly safe to use ThreadStatic variables.
This was about console application; lets take ASP.NET application in consideration. .NET takes thread from ThreadPool to execute the request. This thread is persisted in ThreadPool even though the values of ThreadStatic variables are not getting persisted.
Check-out my ASP.NET example and observe thread static behavior in PageLoad method.
In short; make the best use of ThreadStatic without any fear.
