9

I am reading an article about HttpContext and CallContext and see thread-agility. What does it mean?

Mark Rucker
  • 6,952
  • 4
  • 39
  • 65
masoud ramezani
  • 22,228
  • 29
  • 98
  • 151
  • possible duplicate of [How is ASP.NET multithreaded?](http://stackoverflow.com/questions/657735/how-is-asp-net-multithreaded) – Erik Philips Jul 03 '12 at 08:17
  • 2
    Thread-Agility basically means the thread the request is being processed could be changed during the execution of the request. – Nico Jul 03 '12 at 08:19
  • 1
    As per this link http://blog.idm.fr/2010/03/aspnet-thread-agility-or-why-threadstatic-should-not-be-used.html In ASP.Net, the container might well decide to switch the thread in the middle of the processing of the request. This is called thread agility. – HatSoft Jul 03 '12 at 08:25

1 Answers1

12

It means that IIS is free to use more than one thread to handle a single request, although not in parallel.

Basically, IIS tries to perform I/O operations asynchronously, thus freeing the calling thread for the duration of the operation. That thread is returned to the pool and can be used to handle other requests in the meantime.

When the asynchronous I/O operation completes, control can be returned to a thread other than the one that originally handled the request (since that thread can be busy elsewhere), so the request can continue being processed as soon as possible.

Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
  • 2
    And the only small problem with this is that it can randomly break code. For example, the EntLib data access block from Microsoft's own "Patterns and Practices" group sometimes mixed up request-response so you'd get the response to a different query than the one you started, if the thread happened to change. This was at least fixed (in EntLib v5.0), but really the bug is in ASP.NET, which is supposed to support any managed code. You shouldn't have to know if the implementation of your third-party library uses this feature or that of the FW/CLR. – The Dag Apr 17 '13 at 07:36
  • 1
    I found out about thread agility the hard way. Using log4net, assigning request properties to a ThreadContext I ended up with log messages logged with the wrong request URL, username and IP address. See [log4net Context problems with ASP.Net thread agility](http://piers7.blogspot.nl/2005/12/log4net-context-problems-with-aspnet.html). – R. Schreurs May 02 '14 at 20:10
  • Yep, can't use ThreadContext or CurrentPrincipal for storing data. Instead you have to use HttpContext.Item and HttpContext.User respectively. – John Wu May 22 '15 at 20:50
  • 1
    @JohnWu Which ties all your business logic to the ASP.NET context, plus makes it impossible to unit test. A property public static SomeThing Current backed by CallContext cold be set up in a unit test, but one backed by HttpContext can't be. Basically, you cannot use any kind of thread storage mechanism to provide per-thread separation, and all because ASP.NET does not migrate thread-local storage when switching threads. It is very strange to defend this obvious design *mistake* in ASP.NET - it created traps that Microsoft themselves fell into! – The Dag Oct 26 '15 at 12:00