113

In my Application I have a static method that is called from multiple threads at the same time. Is there any danger of my data being mixed up?

In my first attempt the method was not static and I was creating multiple instance of the class. In that case my data got mixed up somehow. I am not sure how this happens because it only happens sometimes. I am still debugging. But now the method is static on I have no problems so far. Maybe it's just luck. I don't know for sure.

Jim Aho
  • 9,932
  • 15
  • 56
  • 87
TalkingCode
  • 13,407
  • 27
  • 102
  • 147
  • Related posts - [Are static methods thread safe](https://stackoverflow.com/q/1090650/465053) & [C# - Are Parameters Thread Safe in a Static Method?](https://stackoverflow.com/q/17242732/465053) – RBT Jun 28 '18 at 00:10

4 Answers4

120

Variables declared inside methods (with the possible exception of "captured" variables) are isolated, so you won't get any inherent problems; however, if your static method accesses any shared state, all bets are off.

Examples of shared-state would be:

  • static fields
  • objects accessed from a common cache (non-serialized)
  • data obtained via the input parameters (and state on those objects), if it is possible that multiple threads are touching the same object(s)

If you have shared state, you must either:

  • take care not to mutate the state once it can be shared (better: use immutable objects to represent state, and take a snapshot of the state into a local variable - i.e. rather than reference whatever.SomeData repeatedly, you read whatever.SomeData once into a local variable, and then just use the variable - note that this only helps for immutable state!)
  • synchronize access to the data (all threads must synchronize) - either mutually exclusive or (more granular) reader/writer
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 1
    @Marc I can't fully agree with "Variables declared inside methods (with the possible exception of "captured" variables) are isolated". Consider a file handle which is declared in a static method. Then one thread may access the handle when some other thread using it. It will lead to unexpected behavior. Or does your "captured" variable meant "file handle" too. – prabhakaran Aug 01 '12 at 13:32
  • 12
    @prabhakaran if a file handle is a method variable, it is scoped **only** to that caller. Any other caller will be talking to a different *variable* (method variables are per-call). Now, access to **the underlying file** is a separate issue, but that is unrelated to c# or .NET. If the handle isn't shared, one would expect some kind of mutex/lock if this scenario is likely. – Marc Gravell Aug 01 '12 at 19:58
38

Yes, it's just luck. ;)

It doesn't matter if the method is static or not, what matters is if the data is static or not.

If each thread has its own separate instance of the class with its own set of data, there is no risk of data being mixed up. If the data is static, there is only one set of data, and all threads share the same data, so there is no way to not mix it up.

When your data in separate instances still gets mixed up, it's most likely because the data is not really separate.

Pang
  • 9,564
  • 146
  • 81
  • 122
Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • 12
    Loved that line - `It doesn't matter if the method is static or not, what matters is if the data is static or not`. Just to add, the local variables declared within the scope of a static method don't form that part of data which we need to be bothered about in the given scenario. – RBT Jun 27 '18 at 23:51
  • great answer. Helped out a lot. – Fractal Aug 07 '19 at 20:32
19

Static methods should be fine for multiple threads.

Static data on the other hand could cause a problem because attempts to access the same data from different threads needs to be controlled to ensure that only one thread at a time is reading or writing the data.

Doug Ferguson
  • 2,538
  • 2
  • 16
  • 23
12

MSDN Always says :

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Edit: As the guys here say, is not always the case, and clearly this applies to classes designed this way in the BCL, not to user created classes where this does not apply.

Marcote
  • 2,977
  • 1
  • 25
  • 24
  • 3
    Phew! Finally, I understood the meaning of this note which is found so frequently in MSDN documentation. So basically, when MS designs a static method (where this note is published) in BCL they don't access any variable/member/state which is outside the scope of that method. They rely completely on method scoped local variables only for implementing that method's logic. Very glad that you shared. – RBT Jun 28 '18 at 00:03
  • @Marcote, isn't the opposite true? Instance members are safe because there is one per instance. However, static members are not thread safe because they are shared among all instances of that class? https://www.quora.com/Object-Oriented-Programming-Whats-the-difference-between-instance-members-and-static-members – Fractal Aug 07 '19 at 20:43
  • 1
    it depends. I would never treat an instance member safe by default. That's why a whole set of libraries and to avoid data corruption among many other things. – Marcote Aug 08 '19 at 00:00
  • 1
    okay, Thanks @Marcote. I am slowly figuring out that I have a lot to learn. – Fractal Aug 08 '19 at 04:05