Just to add to the discussion (why not?): yes, a static
property is shared across all instances of a class, regardless of thread (unless the backing field is marked ThreadStatic
, that is!). But yes, there are potential multithreading issues you have to face when dealing with such properties. Here's the scenario I think others are getting at.
Consider this code:
int x = MyClass.StaticProperty;
MyClass.StaticProperty = x + 1;
The preceding is a very simple example of where a race condition could cause two threads to perform what is supposed to be two indivisible actions, but instead ends up being effectively a single action.
To illustrate:
Thread 1 Thread 2
int x = MyClass.StaticProperty; // Let's say
int x = MyClass.StaticProperty; // this is 1.
MyClass.StaticProperty = x + 1; // OK, so x is
MyClass.StaticProperty = x + 1; // now... 2.
Do you see the problem? Two threads might both read the property's value before either one writes to it; and the value being written to it is dependent on the value read, which was identical for both threads!
In simple scenarios like the one above, there is a handy class provided in the System.Threading
namespace that can make multithreaded reads/writes fairly painless to implement: Interlocked
. For example to increment StaticProperty
above in a thread-safe way, you might update MyClass
as follows:
class MyClass
static int _staticProperty;
public static int StaticProperty
{
get { return _staticProperty; }
}
public static int IncrementProperty()
{
// increments _staticProperty ATOMICALLY
// and returns its previous value
return Interlocked.Increment(_staticProperty);
}
}
In more complex scenarios (i.e., when you're not simply modifying plain numerical fields in a straightforward way), you may need to devise your own synchronization strategy, the most common of which is to have a designated lock object and simply lock
on it for every operation you want to behave atomically.