ASP.NET has its own thread pool. In an effort to increase performance, the ASP.NET runtime will return threads to the thread pool if a process is blocking so that it can be handed off to other incoming requests. When the blocking process returns, ASP.NET will randomly pick a thread in the pool and that process can continue executing. The interesting thing is that this may not be the same process that the request originally began executing on. Most of the time you never even notice this is happening. That is until you introduce the ThreadStaticAttribute.
The ThreadStaticAttribute causes feilds marked with the static keyword to be unique to each thread. In other words each thread gets its own copy of that static value. It has a unique quirk. You cannot set its value via a static constructor, or by in place
declaration and assignment like so:
// Example 1
public class Baz
{
// all of these only get executed once
// when the .NET runtime loads the class
[ThreadStatic]
static int foo = 1;
[ThreadStatic]
static int bar;
static Baz()
{
bar = 3;
}
}
This is because the .NET runtime only executes static constructors and in place assignment once when the class is loaded, therefore you cannot be sure if your thread is the one that loaded this class. You can however initialize it in any operation you call which is usually static itself. The following example uses two thread static fields to store a resource that needs to be refreshed hourly. The refresh is lock free at the expense that each thread has its own copy. This copy is stored in what is commonly referred to as thread local storage.
// Example 2
public class Baz
{
[ThreadStatic]
static DateTime _lastLoaded;
[ThreadStatic]
static Resource _resource;
static TimeSpan timeout = new TimeSpan(1, 0, 0); // one hour
public static Resource ProcessStuff()
{
if (_lastLoaded.Add(timeout) < DateTime.Now)
{
_resources = GetResourcesFromExternalLocation();
_lastLoaded = DateTime.Now;
}
return _resource;
}
}
The thread local storage ensures that the values in _resource and _lastLoaded are the values created by the thread executing ProcessStuff(). This is rather efficent. However when ASP.NET joins the picture, meyham ensuse.
Remember from earlier that ASP.NET will recycle threads. Basically when you begin an operation, at any point, it could be put to sleep, and its thread recycled. When ASP.NET decides it time to wake up the operation it randomly chooses a thread from the pool to resume execution of the operation. The thread used to continue the operation has all of the thread static values from the last operation using it. Locks do not fix this problem.
Posts
