2

Im working on a multithreaded application, therefore, I was always trying not to use private fields that may raise a conflict in the type instance i was using in different threads. Instead, I have been hauling information i needed to work as method parameters. This led to dozens of methods that all declared the same parameters:

private void MySubmethod(MyConfiguration configuration)

Now i was thinking to redesign the type and creating one instance per thread working, but then i stumbled upon the ThreadStatic attribute.

Is it a good idea to just declare a private threadstatic field, initialize it inside the main method each thread is calling and reuse this field inside all sub-methods, rendering the parameter obsolete? Or has it any drawbacks, so that i rather should concentrate on creating a new instance per Thread?

[ThreadStatic]
private static MyConfiguration _configuration;
Udontknow
  • 1,472
  • 12
  • 32
  • It's very hard to tell that without knowing more about what you're trying to achieve. In *most* cases I'd avoid thread statics though. – Jon Skeet Jul 11 '14 at 12:41
  • Well, it thought that would be a rather general question, therefore i tried to stay generic... I may add that a single unit of work is completely done by a single thread, there is no "thread hopping" inside the execution of the existing main execution method. – Udontknow Jul 11 '14 at 12:46
  • If you use .NET 4.0 (or higher) I'd suggest using `ThreadLocal` instead of `ThreadStaticAttribute` for less "magical stuff" ;-). @JonSkeet is of course right, very hard to give advice without more context - I second his advice to avoid thread-local fields as much as possible and work on the bigger picture to support parallelization better. – PermaFrost Jul 11 '14 at 12:50

1 Answers1

2

Is it a good idea to just declare a private threadstatic field, initialize it inside the main method each thread is calling and reuse this field inside all sub-methods, rendering the parameter obsolete?

No, it is not; it means that any code that touches threads is now deeply unreliable; and with things like ThreadPool, the TPL and async/await, threads are inevitable in modern applications (even if they are implicit rather than explicit in your code). Variables that are thread-dependent are also hugely problematic to debug. Unless there is a very good reason, my advice would be to retain the over-arching context, or plug into an existing robust implementation. For example, in a web application you might reasonably access the current request via the static methods - but even that you need to be careful to know whether you are on the request thread, vs on a worker thread that should have had everything it needed to know handed to it on a plate.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I'd also add that passing in the data required by your method makes your code more test-able. It lowers coupling and dependency and allows units of test to be created. The more state dependency across your application the less maintainable it will be – PhillipH Jul 11 '14 at 12:59