54

What are differences between CallContext and ThreadStatic?

I've understood that in an ASP.NET environment data stored in CallContext could be persisted throughout the request until it ends while ThreadStatic may or may not work since the request may switch threads. I've also learned that the HttpContext is internally stored using the CallContext.

In a regular application they both seem to persist throughout the same thread call. When isn't this the case?

Edit: In the comments I learned that the call context is an abstraction over a thread static store. The ASP.NET framework explicitly moves the data from one thread to the next that is to handle one request. Other framework that wants to provide thread agility could do the same to for contextual storage.

mafu
  • 31,798
  • 42
  • 154
  • 247
Cristian Libardo
  • 9,260
  • 3
  • 35
  • 41

2 Answers2

35

Very often a request will use the same thread throughout, but it certainly won't always be the case - ASP.NET exhibits thread agility. There's an old in-depth blog article about the matter from 2005, but as of .NET 4.5 things are rather better.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • That spring.net thread was in the back of my head when I asked (points for linking). I was particularly looking for details related to the non-web case. Are they essentially the same? – Cristian Libardo Nov 07 '08 at 20:05
  • What do you mean by the non-web case? It really depends on what you're doing - if you know you're in a single thread, it's okay to use ThreadStatic. – Jon Skeet Nov 07 '08 at 20:29
  • I mean an application not affected by the ASP.NET abstractions. CallContext and ThreadStatic seems to work the same way, i.e. they seem to have the same lifetime. I'm interested in learning the differences between the two. – Cristian Libardo Nov 07 '08 at 21:07
  • ThreadStatic is explicitly related to the thread. Any other framework might decide to use thread agility in the same way as ASP.NET. CallContext is a way of taking some context with you when you do. – Jon Skeet Nov 07 '08 at 21:13
  • Stumbled in here and wondered what your rep was when you answered this... 246. –  Feb 22 '17 at 19:52
  • The first link is unfortunately dead by now. Also, the problem described in the article behind the second link seems to not be relevant anymore, as of .NET 4.5 (see https://blog.stephencleary.com/2013/04/implicit-async-context-asynclocal.html). – Zero3 Jun 11 '19 at 16:21
15

Items stored as ThreadStatic are available to more than one request. IIS reuses the thread after a request is complete to process subsequent requests, it can even swap a request from one thread to another during processing. ASP.Net clears down the CallContext after each request.

Martin Brown
  • 24,692
  • 14
  • 77
  • 122
  • 4
    It's more than that though - one request can hop across threads, so what you put in a ThreadStatic in one phase not be available in a different one. – Jon Skeet Nov 07 '08 at 19:34
  • 1
    What is the mechanism that maintains the call context between threads serving the same request? – Cristian Libardo Nov 07 '08 at 21:10
  • 3
    ASP.NET's thread agility handling, basically. I suspect it's a ThreadStatic internally, and when one thread stops dealing with a request for whatever reason, ASP.NET keeps the request and context together, then resets it in whatever thread picks up the work. – Jon Skeet Nov 07 '08 at 21:14
  • 1
    Okay, I have learned that the call context is an abstraction over a thread static store and that the ASP.NET framework explicitly moves the data from one thread to the next one handling the request. – Cristian Libardo Nov 07 '08 at 21:38
  • @Jon: Is Thread Agility behaviour true for WCF as well? Is it safe to use ThreadStatic in WCF application to store request specific data? – Amitabh Mar 26 '10 at 16:23