ThreadStatic FUD

I noticed this morning that Scott Hanselman gave his blog a facelift. I also noticed that I had missed a flurry of post by him. On an ordinary day, by my reckoning, Scott is a heavy blogger. Apparently travel ups the volume that much more. FWIW, I tend to agree with most everything he has to say, and I have much respect for him.

Now.

He discusses storing things on threads and references previous post on the evils of ThreadStaticAttribute in the [Http]Context of ASP.NET. I think a bit of clarification is in order.

1. ThreadStaticAttribute is not harmful in ASP.NET *if* you use it in a way that takes into account the context (sic) in which you are using it.
2. Thread Local Storage suffers from problems similar to ThreadStaticAttribute in contexts where you do not control the lifecycle of the threads in the application, e.g. anywhere that uses the default ThreadPool, e.g. ASP.NET.

On point 1. If you initialize a ThreadStatic variable at the beginning of a request, and you properly dispose of the referenced object at the end of the request, I am going to go out on a limb and claim that nothing bad will happen. You're even cool between contexts in the same AppDomain.

Now, if you expect that variable to follow you outside the process, e.g. in a web service call, of course, you are wrong. If you expect the variable to magically jump from the currently executing thread onto a new thread that you spawn (via either of new Thread(...) or BeginInvoke and friends), then you are smoking something.

You may have problems if the assembly in which the ThreadStatic variable is not domain neutral, i.e. reloaded for each AppDomain in the process. In fact, you may have problems in spite of that. I haven't written any tests to verify either way, though.

All that being said, in the nominal use of ASP.NET (each request gets exclusive access to a thread for its lifetime and doesn't spawn any additional threads that require access to value referenced by the variable), then I think you'll be ok.

Now, I could be wrong on this. The clr could potentially stop a managed thread mid-stream, serialize out its stack somewhere, give it a new stack, and let it start executing. I seriously doubt it. I suppose that it is conceivable that hyperthreading makes things difficult as well, but I also doubt that.

On point 2: If you use slots in thread local storage on a ThreadPool thread and you don't clear out the data associated with the slot, it is going to be there when you get back in the context of another request, so expect that.

It is very likely that the objects that you are going to want to hold on to in some context-affine manner, be it a roll-your-own context affinity such as thread local or threadstatic, or a framework provided version such as Context, are expensive things like transactions, and further they either are or are holding onto scarce resources. For scalability reasons, regardless of how you approach the problem, you will want to make sure to let go of these objects, potentially disposing of them as early as possible to release the resources.

So -- the challenge (heh): Scott, if you can prove me wrong I will buy you a steak [assuming you like steak] dinner when you are here in Dallas for the .NET UG meeting in November (unless our paths serendipitously overlap before then).

I'll try to throw some sample code up to support these points at a later point. I would love to be wrong, because then I would probably learn something very tricky and interesting about what .NET keeps under its kilt. I just don't think I am.

Comments

[Scott Hanselman]

FUD is a strong word! ;) The point I was tring to make with that post, and this one (http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx) was that you really ought not use ThreadStatic in ASP.NET for storage of Private Data. If something goes wrong (exception in a place you can't grab) you will orphan your thread local storage, and it will still be around when the next request is serviced by that thread. The point was that HttpContext != ThreadLocalStorage. HttpContext.Items is there to give ASP.NET programmers the behavior they want...the behavior they think of as "thread local." I wasn't trying to say BAD things would happen...I was trying to say, basically (poorly), that if the average ASP.NET programmer stumbles on ThreadStatic in MSDN, they may think it's useful and get unexpected results. It's not for eveyday public use within ASP.NET. Can you think of a reason to use ThreadStatic over the various other options in ASP.NET. You're right about point 2, though.

[enrico]

I agree totally with the post. I mean, I bumped into Scott Hanselman post as well and I was quite puzzled about how he warned against using the ThreadStaticAttribute. In my opinion it was ok to use ThreadStaticAttribute as long one consider the implications you mention. AND it's much better to use a neutral object such as TLS or ThreadStaticAttribute than ASP.NET specific object or your framework / business layer / data layer code won't port very well to another kind of UI. IMHO

[nekit]

I was looking agound for the similar thing and kept hearing (reading) "thread agile, thread agile, thread agile" everywhere. Basically what I read was that ASP.NET is not only thread pooled, but also thread agile, which means it may switch threads during request processing and serve multiple active requests with one thread. (and may be even one request may be processed by different threads). So if this is right, it doesn't do exacly what you assume it does ("...each request gets exclusive access to a thread for its lifetime..."). This makes ThreadStatic unusable. (http://groups-beta.google.com/group/microsoft.public.dotnet.framework.aspnet/browse_frm/thread/cef5d88a2e3e26e1/85798178bdf7c0c8?q=asp.net+thread+agile&rnum=1#85798178bdf7c0c8)

[Steve Willcock]

re. point 2 concerning Thread Local Storage, surely this must be safe in ASP.NET (as long as you clean up after yourself!). One thing that seems to point to this is that (according to my reading of Lutz Roeder's reflector) a call to HttpContext.Current ultimately calls either Thread.CurrentThread.GetLogicalCallContext().GetData("HtCt"); or Thread.CurrentThread.GetIllogicalCallContext().GetData("HtCt");. Reading between the lines, this usage of CurrentThread to get the current HttpContext seems to indicate that thread local storage must be safe for the duration of a request? I agree with enrico that using TLS rather than HttpContext.Items etc. is a good mechanism to ensure portability of your code between environments other than ASP.NET - e.g. windows service, console or winforms apps.

[piers7]

Unfortunately even if you clean up after yourself in EndRequest, neither CallContext nor ThreadStatic can actually be trusted in ASP.Net due to thread agility *during a request's lifetime*. nekit is right, though the link doesn't really explain fully. I've posted on my blog about this, because it bit me (see link)