« HMM, could it be.... | Main | ThreadStatic (again) »



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.
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
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.
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)

The comments to this entry are closed.

November 2008

Sun Mon Tue Wed Thu Fri Sat
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Blog powered by Typepad

We Like