Does changing the culture of a threadpool thread affect it when it gets returned back to the pool?

Question

If I set the CurrentCulture of a thread pool thread, what happens when the thread finishes execution and gets returned back to the thread pool? Does it get its CurrentCulture reset back to the default (whatever that may mean), or will it retain the culture I have set on it?

I'm hoping that the framework resets the thread to a default state to guard against this, but cannot find any documentation to this effect. The closest I have found is from the MSDN docs for ThreadPool:

When the thread pool reuses a thread, it does not clear the data in thread local storage or in fields that are marked with the ThreadStaticAttribute attribute. Therefore, data that is placed in thread local storage by one method can be exposed to any other method that is executed by the same thread pool thread.

This seems to indicate that the thread is not reset when it is returned.

I have tried some sample code to try to test this, and it does seem that the culture is reset, but I am not convinced that I am testing this behaviour correctly as I think I am only using a small subset of the ThreadPool's threads, and so cannot be sure I'm testing a thread that has already had it's culture set.

Encephalon

Slightly related, but mainly for reference: twitter.com/#!/Wintellectuals/status/27733481381 – Encephalon

Answer 1

I would not rely on the ThreadPool ever resetting information, specifically because of the text you quoted.

If you are worried about "changing" the thread pool's culture, I would make sure to reset it when your threaded task is complete. This is a simple enough task.

I do not believe the current threadpool does this, but even if it did, it would not be safe to assume that .NET 4+'s ThreadPool implementation will not change.

Diegodiehard

This is more of a theoretical question really. I'm not doing this, but came across a situation whereby a new thread runs in a different culture than the main thread (as is the specified behaviour). I was curious to know what happens, as it would be easy to forget to set the culture back once the thread is done. – Encephalon

When the ThreadPool creates new threads, they'll use the culture of the AppDomain containing the thread. Changing it does, btw, persist - but you never know if you're going to "reuse" that thread, and the threadpool does retire threads, so it's pretty much causing undefined, unpredictable behavior. – Diegodiehard

@Reed Copsey - In this case, how can I find the "culture of the AppDomain". I can find reference to a Thread's culture, but not the AppDomain. The reason I ask is I am using the System.Threading.Task API to create background tasks and I believe the default implementation uses ThreadPool. The threads that are spawned seem to have the default system culture, rather than any cultures I've set on parent threads. I wanted a way to set the default culture for the entire app, but I've not found a way to do this. – Ilan

@Anderson: I'd store your main thread culture, and pass it to the Task instances as needed. Most tasks, since they're background operations, don't really worry about culture anyways - so it should be a rare thing to require. Any task scheduled on the UI will automatically pick up the UI culture... – Diegodiehard

@Reed Copsey: Yeah, I've been passing them through closures at the moment. Your mention of an "AppDomain culture" was hopeful to me; that's what I was looking for, but it doesn't seem like that's actually a feature. In a WPF app, there are times when I need to fetch data off the UI thread. Frequently this data is meant for display, but its translation information is stored in the datastore, so I need to pass the right culture along with the query on that background thread. I agree that if I was using culture to pull resources, etc, I'd just do it on the UI thread at the presentation layer. – Ilan

@Anderson: Typically, in cases like you're describing, I do the translation in the UI thread, and pass the culture-mapped data into the processing backend/datastore. It tends to avoid the issue entirely. (I want to do this because it makes handling improperly formatted data easier - it's already on the right thread, and those routines are fast...) – Diegodiehard