a viable solution to this problem?

I am calling from one piece of my code through several layers of 3rd party code, and the call surfaces back into my code at some point by callin开发者_StackOverflow中文版g some code I've written.

In other words, the code call chain looks like this:

My code #1 --> 3rd party code --> My code #2

Unfortunately, nothing I pass to the 3rd party code is given to that second piece of code so I have nothing to tie the first piece and the second piece together, except for the fact that the code runs on the same thread.

So I was wondering if simply using [ThreadStatic] on a static field on a class would be a viable solution to this?

Since the code also runs in a web application, I cannot just use a static field for this, since the value I need access to (an object) is different for each user/session.

ie. I would do something like this:

internal static class DataHolder
{
    [ThreadStatic]
    internal static ClassName FieldName;
}

Are there other solutions to this?

---

In contrast to the other answers suggesting that this is ok, you should be very careful about using ThreadStatic or ThreadLocal<T> in an ASP.NET application.

ASP.NET utilises thread-agility, meaning that the same request can potentially be handled by several threads. To be safe you'd need to break encapsulation and store your items in the current HttpContext, rather than using ThreadStatic or ThreadLocal<T>:

internal static class DataHolder
{
    internal static ClassName PropertyName
    {
        get { return (ClassName)System.Web.HttpContext.Current.Items["foo"]; }
        set { System.Web.HttpContext.Current.Items["foo"] = value; }
    }
}

Unfortunately this thread-agility "feature" is very poorly documented. I'm reasonably sure that the thread switch can only happen at certain points in the lifecycle, not arbitrarily, so depending on exactly how and where in the lifecycle the code is used you might be safe with ThreadStatic or ThreadLocal<T>.

I'll try to dig out some links...

---

Yes. ThreadStatic will work for that. You might want to look into ThreadLocal, which simplifies working with thread static variables.

---

Yes, [ThreadStatic] should work in the scenario you describe if you can be absolutely certain that the 3rd party code always calls you back on the same thread that you called into the 3rd party code on. In many async callback models, this is often not guaranteed. If the callback is strictly defined as a synchronous callback, then you're probably ok.

---

ThreadLocal<T> for .NET 4 as mentioned in this question:

are static classes shared among different threads in C#

However, having been in that boat myself - I ended up going down the static route. It worked and was safe because it was manageable state.