Are local variables within static methods thread safe?

Question

If I have a static class with a static method, are the local variables within the method safe if multiple threads are calling it?

static class MyClass {    static int DoStuff(int n) {      int x = n; // <--- Can this be modified by another thread?      return x++;        } } 

Answer 1

Answers to this question which state that locals are stored on the stack and are therefore threadsafe are incomplete and perhaps dangerously wrong.

Do threads create their own scope when executing static methods?

Your question contains a common error. A "scope" in C# is purely a compile-time concept; a "scope" is a region of program text in which a particular entity (such as a variable or type) may be referred to by its unqualified name. Scopes help determine how the compiler maps a name to the concept that the name represents.

Threads do not create "scopes" at runtime because "scope" is purely a compile-time concept.

The scope of a local variable is connected -- loosely -- to its lifetime; roughly speaking, the runtime lifetime of a local variable typically begins when a thread of control enters code corresponding to the beginning of its scope, and ends when the thread of control leaves. However, the compiler and the runtime are both granted considerable discretion to lengthen or shorten that lifetime if they deem that doing so is efficient or necessary.

In particular, locals in iterator blocks and closed-over locals of anonymous functions have their lifetimes extended to beyond the point where control leaves the scope.

However, none of this has to do with thread safety. So let's abandon this badly-phrased question and move on to a somewhat better phrasing:

If I have a static class with a static method, are the instance variables within the method safe if multiple threads are calling it?

Your question contains an error. Instance variables are non-static fields. Obviously there are no non-static fields in a static class. You are confusing instance variables with local variables. The question you intended to ask is:

If I have a static class with a static method, are the local variables within the method safe if multiple threads are calling it?

Rather than answer this question directly I'm going to rephrase it into two questions that can more easily be answered.

Under what circumstances do I need to use locking or other special thread-safety techniques to ensure safe access to a variable?

You need to do so if there are two threads, both can access the variable, at least one of the threads is mutating it, and at least one of the threads is performing some non-atomic operation on it.

(I note that there may be other factors at play as well. For example, if you require consistently observed values of shared memory variables as seen from every thread then you need to use special techniques even if the operations are all atomic. C# does not guarantee sequential consistency of observations of shared memory even if the variable is marked as volatile.)

Super. Let's concentrate on that "both can access the variable" part. Under what circumstances can two threads both access a local variable?

Under typical circumstances, a local variable can only be accessed inside the method which declares it. Each method activation will create a different variable, and therefore no matter how many times the method is activated on different threads, the same variable is not accessed on two different threads.

However, there are ways to access a local variable outside of the method which created it.

First, a "ref" or "out" parameter may be an alias to a local variable, but the CLR and the C# language have both been carefully designed so that aliases to local variables are only accessible from methods which were called by the method declaring the variable (directly or indirectly). Therefore, this should still be threadsafe; there should not be a way to get a ref from one thread to another, and thereby share the variable across threads.

Second, a local variable might be a closed-over local of a lambda or anonymous method. In this circumstance a local variable is not necessarily threadsafe. If the delegate is stored in shared memory then two threads can manipulate the local independently!

static class Foo {     private static Func<int> f;     public static int Bar()     {         if (Foo.f == null)         {            int x = 0;            Foo.f = ()=>{ return x++; };         }         return Foo.f();     } } 

Here "Bar" has a local variable "x". If Bar is called on multiple threads, then first the threads race to determine who sets Foo.f. One of them wins. And from now on, calls to Bar on multiple threads all unsafely manipulate the same local variable x which was captured by the delegate created by the winning thread. Being a local variable is not a guarantee of thread safety.

Third, a local variable inside an iterator block has the same problem:

static class Foo {     public static IEnumerable<int> f;     private static IEnumerable<int> Sequence()     {         int x = 0;         while(true) yield return x++;     }     public static Bar() { Foo.f = Sequence(); } } 

If someone calls Foo.Bar() and then accesses Foo.f from two different threads, again a single local variable x can be unsafely mutated on two different threads. (And of course the mechanisms which run the iterator logic are also not threadsafe.)

Fourth, in code that is marked as "unsafe" a local variable may be shared across threads by sharing a pointer to the local across threads. If you mark a block of code as "unsafe" then you are responsible for ensuring that the code is threadsafe if it needs to be. Don't turn off the safety system unless you know what you are doing.