We Keep Coding

Static or Non Static methods, thread safety is for the types not methods

I have this confusion for sometime, are static method implementation threads safe, instance methods are certainly thread safe, if we assign a separate instance to each thread, then they do not meddle, then I have realized that, thread safety is more about types then methods, which are in themselves not a memory allocation, so let's take an example:
private static ConcurrentDictionary<int,int> cd;
public static void Method1(int userid)
{
// Modify static object cd based on userid key
}
public void Method2(int userid)
{
// Modify static object cd based on userid key
}
In essence there's no difference between two methods when accessed by multiple threads supplying different user ids at run time. I have tested the same but want to verify if my understanding is correct.

Static methods are not thread-safe because they are static.
They are thread-safe because someone made them thread-safe. Typically in the .NET framework, static methods are thread-safe because someone wrote them that way.
You can just as easily write non-thread-safe static members, there's no magic being done here.
The exact same rules you would have to follow to write a thread-safe instance member must be followed to write thread-safe static members.

are static method implementation threads safe?
No, if they modify shared data, then they are just as non-thread safe. Your example could be OK but only because the shared data is threadsafe itself being a ConcurrentDictionary of immutable types (ints).
instance methods are certainly thread safe, if we assign a separate instance to each thread
Well no, if an instance is accessed by a single thread then that doesn't make it threadsafe. That's just avoiding multi-thread issues.
In short static has nothing to do with multi-threading.

Thread Safety has nothing to do with classes and instances of classes. Both can be used in a unsafe manner for threading.
But ussually objects like winforms controls can't access their resources from other threads, thus they check if you accessing them from other thread and you must make sure you use Invoke to use the desired thread for that control...

instance methods are certainly thread safe, if we assign a separate instance to each thread
Yes when a thread constructs an object only this thread has a reference to the object no other thread can access that object and no thread synchronization is required when invoking instance methods.
Thread-safety does not means synchronization
Thread-safe means that data doesn't get corrupted if two threads attempt to access the data at the some time.Thread-safe also depends on which type you are Reading and writing a data type that fits into a single word (int on a 32-bit processor, long on a 64-bit processor) is thread-safe.
Synchronization it's a way to achieve thread safety but, Immutability of objects too.
Back on your question, if for example your thread exposes the reference to the object by a static field and passing it as state argument to another thread's method here synchronization is required if the threads could attempt simultaneous write access (but not read-only which is different from read and write access)
So having an object(not related to a method) (static or instance) that can be accessed by many threads at the same time in read and write should be made thread safe.

Thread-safety of static initializers in C#

Everyone says static initializers are thread-safe, but I'm worried about a particular detail.
Let's say I have
static class MyStaticClass
{
public static readonly object myField = MyOtherClass.GetNewObject();
}
static class MyOtherClass
{
public static object GetNewObject()
{ /* arbitrary code that returns a new object */ }
}
Which of the following does C# guarantee, when MyStaticClass.myField is not yet initialized?
If threads 1 and 2 try to access myField together (in that order), GetNewObject will have started executing before thread 2 reads myField.
If threads 1 and 2 try to access myField together (in that order), GetNewObject will have finished executing before thread 2 reads myField.
How about the CLR in general: if its guarantees differ from C#'s, in what ways do they differ?
Has the behavior changed in more recent versions of the .NET framework?
Note:
It's a tricky question, and I think a complete answer would probably mention the difference between a static constructor and a static initializer, and how they interact with beforefieldinit to produce the claimed result.

Case 2 will be honoured. A class field, property, or method cannot be dereferenced until the type has been initialized, and the type will not be initialized until the static constructor is completed. The static constructor is, to the best of my knowledge, therefore a blocking call.
http://msdn.microsoft.com/en-us/library/aa645612(v=vs.71).aspx
"The static constructor for a class executes at most once in a given application domain."
See this reply from Eric Lippert: https://stackoverflow.com/a/9399027/2420979 and note that "cctor" is IL for static constructor.
No cctors call MyMethod, directly or indirectly! Now is it ever possible for a static method like MyMethod to be called before the cctor of MyClass completes?
No.
Is that still true even if there are multiple threads involved?
Yes. The cctor will finish on one thread before the static method can be called on any thread.
Can the cctor be called more than once? Suppose two threads both cause the cctor to be run.
The cctor is guaranteed to be called at most once, no matter how many threads are involved. If two threads call MyMethod "at the same time" then they race. One of them loses the race and blocks until the MyClass cctor completes on the winning thread.

Taken from MSDN:
Static members are initialized before the static member is accessed for the first time and before the static constructor, if there is one, is called.
If you second method is run in two different threads but never use the static class, it will never be built. However, if there is a reference to it, it will be initialized before any of the two thread access it.

What Makes a Method Thread-safe? What are the rules?

Are there overall rules/guidelines for what makes a method thread-safe? I understand that there are probably a million one-off situations, but what about in general? Is it this simple?
If a method only accesses local variables, it's thread safe.
Is that it? Does that apply for static methods as well?
One answer, provided by #Cybis, was:
Local variables cannot be shared among threads because each thread gets its own stack.
Is that the case for static methods as well?
If a method is passed a reference object, does that break thread safety? I have done some research, and there is a lot out there about certain cases, but I was hoping to be able to define, by using just a few rules, guidelines to follow to make sure a method is thread safe.
So, I guess my ultimate question is: "Is there a short list of rules that define a thread-safe method? If so, what are they?"
EDIT
A lot of good points have been made here. I think the real answer to this question is: "There are no simple rules to ensure thread safety." Cool. Fine. But in general I think the accepted answer provides a good, short summary. There are always exceptions. So be it. I can live with that.

If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack:
In this instance, multiple threads could call ThreadSafeMethod concurrently without issue.
public class Thing
{
public int ThreadSafeMethod(string parameter1)
{
int number; // each thread will have its own variable for number.
number = parameter1.Length;
return number;
}
}
This is also true if the method calls other class method which only reference locally scoped variables:
public class Thing
{
public int ThreadSafeMethod(string parameter1)
{
int number;
number = this.GetLength(parameter1);
return number;
}
private int GetLength(string value)
{
int length = value.Length;
return length;
}
}
If a method accesses any (object state) properties or fields (instance or static) then you need to use locks to ensure that the values are not modified by a different thread:
public class Thing
{
private string someValue; // all threads will read and write to this same field value
public int NonThreadSafeMethod(string parameter1)
{
this.someValue = parameter1;
int number;
// Since access to someValue is not synchronised by the class, a separate thread
// could have changed its value between this thread setting its value at the start
// of the method and this line reading its value.
number = this.someValue.Length;
return number;
}
}
You should be aware that any parameters passed in to the method which are not either a struct or immutable could be mutated by another thread outside the scope of the method.
To ensure proper concurrency you need to use locking.
for further information see lock statement C# reference and ReadWriterLockSlim.
lock is mostly useful for providing one at a time functionality,
ReadWriterLockSlim is useful if you need multiple readers and single writers.

If a method only accesses local variables, it's thread safe. Is that it?
Absolultely not. You can write a program with only a single local variable accessed from a single thread that is nevertheless not threadsafe:
https://stackoverflow.com/a/8883117/88656
Does that apply for static methods as well?
Absolutely not.
One answer, provided by #Cybis, was: "Local variables cannot be shared among threads because each thread gets its own stack."
Absolutely not. The distinguishing characteristic of a local variable is that it is only visible from within the local scope, not that it is allocated on the temporary pool. It is perfectly legal and possible to access the same local variable from two different threads. You can do so by using anonymous methods, lambdas, iterator blocks or async methods.
Is that the case for static methods as well?
Absolutely not.
If a method is passed a reference object, does that break thread safety?
Maybe.
I've done some research, and there is a lot out there about certain cases, but I was hoping to be able to define, by using just a few rules, guidelines to follow to make sure a method is thread safe.
You are going to have to learn to live with disappointment. This is a very difficult subject.
So, I guess my ultimate question is: "Is there a short list of rules that define a thread-safe method?
Nope. As you saw from my example earlier an empty method can be non-thread-safe. You might as well ask "is there a short list of rules that ensures a method is correct". No, there is not. Thread safety is nothing more than an extremely complicated kind of correctness.
Moreover, the fact that you are asking the question indicates your fundamental misunderstanding about thread safety. Thread safety is a global, not a local property of a program. The reason why it is so hard to get right is because you must have a complete knowledge of the threading behaviour of the entire program in order to ensure its safety.
Again, look at my example: every method is trivial. It is the way that the methods interact with each other at a "global" level that makes the program deadlock. You can't look at every method and check it off as "safe" and then expect that the whole program is safe, any more than you can conclude that because your house is made of 100% non-hollow bricks that the house is also non-hollow. The hollowness of a house is a global property of the whole thing, not an aggregate of the properties of its parts.

There is no hard and fast rule.
Here are some rules to make code thread safe in .NET and why these are not good rules:
Function and all functions it calls must be pure (no side effects) and use local variables. Although this will make your code thread-safe, there is also very little amount of interesting things you can do with this restriction in .NET.
Every function that operates on a common object must lock on a common thing. All locks must be done in same order. This will make the code thread safe, but it will be incredibly slow, and you might as well not use multiple threads.
...
There is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location, and this for each function (static or otherwise) that is accessing common objects.

It must be synchronized, using an object lock, stateless, or immutable.
link: http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

can there be concurrency issues when using C# class with only static methods and no variables?

Have I understood correctly that all threads have copy of method's variables in their own stack so there won't be problems when a static method is called from different threads?

Yes and no. If the parameters are value types, then yes they have their own copies. Or if the reference type is immutable, then it can't be altered and you have no issues. However, if the parameters are mutable reference types, then there are still possible thread safety issues to consider with the arguments being passed in.
Does that make sense? If you pass a reference type as an argument, it's reference is passed "by value" so it's a new reference that refers back to the old object. Thus you could have two different threads potentially altering the same object in a non-thread-safe way.
If each of those instances are created and used only in the thread using them, then chances are low that you'd get bit, but I just wanted to emphasize that just because you're using static methods with only locals/parameters is not a guarantee of thread-safety (same with instance of course as noted by Chris).

Have I understood correctly that all threads have copy of method's variables in their own stack so there won't be problems when a static method is called from different threads?
No.
First off, it is false that "all threads have a copy of the method's local variables in their own stack." A local variable is only generated on the stack when it has a short lifetime; local variables may have arbitrarily long lifetimes if they are (1) closed-over outer variables, (2) declared in an iterator block, or (3) declared in an async method.
In all of those cases a local variable created by an activation of a method on one thread can later be mutated by multiple threads. Doing so is not threadsafe.
Second, there are plenty of possible problems when calling static methods from different threads. The fact that local variables are sometimes allocated on the stack does not magically make access to shared memory by static methods suddenly correct.
can there be concurrency issues when using C# class with only static methods and no variables?
I assume you mean "no static variables" and not "no local variables".
Absolutely there can be. For example, here's a program with no static variables, no non-static methods, no objects created apart from the second thread, and a single local variable to hold a reference to that thread. None of the methods other than the cctor actually do anything at all. This program deadlocks. You cannot assume that just because your program is dead simple that it contains no threading bugs!
Exercise to the reader: describe why this program that appears to contain no locks actually deadlocks.
class MyClass
{
static MyClass()
{
// Let's run the initialization on another thread!
var thread = new System.Threading.Thread(Initialize);
thread.Start();
thread.Join();
}
static void Initialize()
{ /* TODO: Add initialization code */ }
static void Main()
{ }
}
It sounds like you are looking for some magical way of knowing that your program has no threading issues. There is no such magical way of knowing that, short of making it single-threaded. You're going to have to analyze your use of threads and shared data structures.

There is no such guarantee unless all of the variables are immutable reference types or value types.
If the variables are mutable reference types, proper synchronization needs to be performed.
EDIT: Mutable variables only need to be synchronized if they are shared between threads- locally declared mutables that are not exposed outside of the method need not be synchronized.

Yes, unless methods use only local scope variable and no any gloval variable, so there is no any way any of that methods can impact on the state of any object, if this is true, you have no problems to use it in multithreading. I would say, that even , in this conditions, static they or not, is not relevant.

If they are variables local to the method then yes, you have nothing to worry about. Just make sure you are not passing parameters by reference or accessing global variables and changing them in different threads. Then you will be in trouble.

static methods can refer to data in static fields -- either in their class or outside of it -- which may not be thread safe.
So ultimately the answer to your question is "no", because there may be problems, although usually there won't be.

Two threads should still be able to operate on the same object either by the object being passed in to methods on different threads as parameters, or if an object can be accessed globally via Singleton or the like all bets are off.
Mark

As an addendum to the answers about why static methods are not necessarily thread-safe, it's worth considering why they might be, and why they often are.
The first reason why they might be is, I think, the sort of case you were thinking of:
public static int Max(int x, int y)
{
return x > y ? x : y;
}
This pure function is thread-safe because there is no way for it to affect code on any other thread, the locals x and y remain local to the thead they are on, not being stored in a shared location, captured in a delegate, or otherwise leaving the purely local context.
It's always worth noting, that combinations of thread-safe operations can be non thread-safe (e.g. doing a thread-safe read of whether a concurrent dictionary has a key followed by a thread-safe read of the value for that key, is not thread-safe as state can change between those two thread-safe operations). Static members tend not to be members that can be combined in such non thread-safe ways in order to avoid this.
A static method may also guarantee it's own thread-safety:
public object GetCachedEntity(string key)
{
object ret; //local and remains so.
lock(_cache) //same lock used on every operation that deals with _cache;
return _cache.TryGetValue(key, out ret) ? ret : null;
}
OR:
public object GetCachedEntity(string key)
{
object ret;
return _cache.TryGetValue(key, out ret) ? ret : null; //_cache is known to be thread-safe in itself!
}
Of course here this is no different than an instance member which protects itself against corruption from other threads (by co-operating with all other code that deals with the objects they share).
Notably though, it is very common for static members to be thread-safe, and instance members to not be thread-safe. Almost every static member of the FCL guarantees thread-safety in the documentation, and almost every instance member does not barring some classes specifically designed for concurrent use (even in some cases where the instance member actually is thread-safe).
The reasons are two-fold:
The sort of operations most commonly useful for static members are either pure functions (most of the static members of the Math class, for example) or read static read-only variables which will not be changed by other threads.
It's very hard to bring your own synchronisation to a third-party's static members.
The second point is important. If I have an object whose instance members are not thread-safe, then assuming that calls do not affect non-thread-safe data shared between different instances (possible, but almost certainly a bad design), then if I want to share it between threads, I can provide my own locking to do so.
If however, I am dealing with static members that are not thread-safe, it is much harder for me to do this. Indeed, considering that I may be racing not just with my own code, but with code from other parties, it may be impossible. This would make any such public static member next to useless.
Ironically, the reason that static members tend to be thread-safe is not that it's easier to make them so (though that does cover the pure functions), but that it's harder to! So hard in-fact that the author of the code has to do it for the user, because the user won't be able to themselves.

Are local variables within static methods thread safe?

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++;
}
}

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.