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.

Static variable population best practice

I have a class Meterage which I expect to be instantiated several times, probably in quick succession. Each class will need to know the location of the dropbox folder in the executing machine, and I have code for this.
The class currently has a variable:
private string dropboxPath = string.Empty;
to hold the path, but I am considering making this a static to save repeated execution of
this.LocateDropboxFolder();
in the constructor. But I am a little concerned by the switch: what if two constructors try to set this at the same time? Would this code in the constructor be safe (LocateDropboxFolder becomes static too in this example):
public Meterage()
{
if (dropboxPath == string.Empty)
{
LocateDropboxFolder();
}
}
I think my concerns are perhaps irrelevant as long as I don't have construction occurring in multiple threads?

If the field is made static then static field initializers or static constructors are the easy way to initialize them. This will be executed at most once in a thread safe manner.
private static string dropboxPath;
static Meterage()
{
LocateDropboxFolder();
}
If you don't want to re-assign the field I suggest you to use readonly modifier, then the code should look like:
private static readonly string dropboxPath;
static Meterage()
{
dropboxPath = LocateDropboxFolder();
}
LocateDropboxFolder needs to return a string in this case.

Variables declared outside the constructor are evaluated before the constructor. Then the constructor will evaluate it.
Do remember that you will end up have only one dropBoxPath. If this is intended, it is okay to do so. Optionally, make LocateDropboxFolder a static method and call it from the static constructor.
If you want to prevent other constructors to overwrite the default, try this:
if (string.IsNullOrEmpty(dropboxPath))
{
LocateDropboxFolder();
}
Or, in a static constructor (at most called once):
static Meterage()
{
LocateDropboxFolder();
}
private static LocateDropboxFolder()
{
...
}

Your example will be safe provided your code is executing synchronously. If multiple instances are created, their constructors will be called in the order they are created.
On the first run through, LocateDropboxFolder() will execute. When this completes, dropboxPath will be set.
On the second constructor execution, LocateDropboxFolder() will not execute because dropboxPath will no longer equal string.Empty (provided 'LocateDropboxFolder()' does not return string.Empty.
However, if LocateDropboxFolder() is asynchronous or the objects are instantiated on different threads, then it is possible to create a second Meterage instance before dropBoxPath has been set by the LocateDropboxFolder() function. As such, multiple calls to the function will likely be made.
If you wish to guard against multithreading errors like this, you could consider using lock statements.

You might potentially end up running the LocateDropboxFolder multiple times if the object tries to be constructed multiple times in close succession from multiple threads. As long as the method returns the same result every time though this shouldn't be a problem since it will still be using the same value.
Additionally if you are setting the value of dropboxPath in the constructor then there is no point setting a default value for it. I'd just declare it (and not assign it) and then check for null in your constructor.

I hava a feeling that your Meterage class is breaking a Single Responsibility Principle. What has the meterage to do with a file access? I would say you have 2 concerns here: your Meterage and, let's say, FolderLocator. the second one should have some property or method like Dropbox which could use lazy evaluation pattern. It should be instantiated once and this single instance can be injected to each Metarage instance.
Maybe not FolderLocator but FileSystem with some more methods than just a single property? Nos sure what you're actually doing. Anyway - make an interface for this. That would allow unit testing without using the actual Dropbox folder.

Race Condition with Static Class?

Let's say I have a static class with a static method.
Multiple threads can call this static method concurrently.
Is there a potential for a race condition under these circumstances:
a - if the method depends only on local variables
b - if the method depends on local variables and member fields

Let's say I have a static class with a static method. Multiple threads can call this static method concurrently.
OK.
Is there a potential for a race condition under these circumstances:
a - if the method depends only on local variables
Yes, there are potential race conditions.
b - if the method depends on local variables and member fields
Yes, there are potential race conditions.
The answers to (a) and (b) are a consequence of a more general rule, namely, there is always the potential for race conditions any time you call any method from multiple threads. For example, this program 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()
{ }
static void Main()
{ }
}
It has no fields, two methods that do absolutely nothing, and a single local variable that is only accessed on a single thread. And nevertheless, it immediately and consistently deadlocks. (Do you see why? See http://ericlippert.com/2013/01/31/the-no-lock-deadlock/ for more on this program.)
It sounds like you are looking for a guarantee that your program is threadsafe if your static methods do not access fields. There is no such guarantee. Your program is threadsafe if and only if you write it to be threadsafe.

First off, a method is simply a piece of code residing at an address. Each thread calling a method will have a copy of that method and its local variables on its own private stack. So in case a, provided there are no other catches, it should be thread-safe.
Case b depends on a lot of factors:
are you actually accessing those member variables?
how are you accessing them: only reads, reads + writes, etc.
what kind of member variables: data structures, single values.
do you have any synchronization in place?
etc.
Generally though, assuming you do access the class members, it should not be considered thread-safe.

A - No. Race conditions only occur when static methods are attempting to access a shared resource. The local variable will be unique to each thread calling the method.
B - Yes. Those static members will be shared by all of the threads calling that method.

How does a static constructor work?

namespace MyNameSpace
{
static class MyClass
{
static MyClass()
{
//Authentication process.. User needs to enter password
}
public static void MyMethod()
{
//Depends on successful completion of constructor
}
}
class Program
{
static void Main(string[] args)
{
MyClass.MyMethod();
}
}
}
Here is the sequence which I assumed
Start of static constructor
End of static constructor
Start of main
Start of MyMethod
End of main
Now in any scenario if 4 will start before 2 I am screwed. Is it possible?

You only asked one question here but there are a dozen or so questions that you should have asked, so I'll answer them all.
Here is the sequence which I assumed
Start of class constructor (also known as cctor)
End of cctor
start of Main
start of MyMethod
Is this correct?
No. The correct sequence is:
Start of cctor for Program, if there is one. There is not.
End of cctor for Program, if there is one. There is not.
Start of Main
Start of cctor for MyClass
End of cctor for MyClass
Start of MyClass.MyMethod
What if there is a static field initializer?
The CLR is permitted to change the order in which static field initializers run in some cases. See Jon's page on the subject for details:
The differences between static constructors and type initializers
Is it ever possible for a static method like MyMethod to be called before the cctor of that class completes?
Yes. If the cctor itself calls MyMethod then obviously MyMethod will be called before the cctor completes.
The cctor does not call MyMethod. Is it ever possible for a static method like MyMethod to be called before the cctor of MyClass completes?
Yes. If the cctor uses another type whose cctor calls MyMethod then MyMethod will be called before the MyClass cctor completes.
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.
The losing thread blocks until the cctor is done? Really?
Really.
So what if the cctor on the winning thread calls code that blocks on a lock previously taken by the losing thread?
Then you have a classic lock order inversion condition. Your program deadlocks. Forever.
That seems dangerous. How can I avoid the deadlock?
If it hurts when you do that then stop doing that. Never do something that can block in a cctor.
Is it a good idea to rely upon cctor initialization semantics to enforce complex security requirements? And is it a good idea to have a cctor that does user interactions?
Neither are good ideas. My advice is that you should find a different way to ensure that the security-impacting preconditions of your methods are met.

According to the MSDN, a static constructor:
A static constructor is called automatically to initialize the class
before the first instance is created or any static members are
referenced.
So the static constructor will be called before the static method MyClass.MyMethod() is invoked (assuming not also invoked during static construction or static field initialization of course).
Now, if you are doing anything asynchronous in that static constructor, then it's your job to synchronize that.

The #3 is actually #1: static initialization does not start until the first use of the class to which it belongs.
It is possible if MyMethod is called from the static constructor or a static initialization block. If you do not invoke MyMethod directly or indirectly from your static constructor, you should be fine.

From the documentation (emphasis mine):
A static constructor is called automatically to initialize the class
before the first instance is created or any static members are
referenced.

You can guarantee 4 will always come after 2 (if you don't create a instance of your class from your static method), however the same is not true for 1 and 3.

The static constructor will be called before mymethod is executed. However if you are screwed if 4 is called before 2 then I suggest you re-think your design. Should not be doing complicated stuff in a static constructor anyway.

The CLR guarantees that the static constructor runs before any static members are accessed. However, your design is a bit smelly. It would be more straightforward to do something like this:
static void Main(string[] args)
{
bool userIsAuthenticated = MyClass.AuthenticateUser();
if (userIsAuthenticated)
MyClass.MyMethod();
}
With your design, if authentication fails, the only way to prevent MyMethod from running is by throwing an exception.

It's ensured that a static class's constructor has been called before any of its methods get executed. Example:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Press enter");
Console.ReadLine();
Boop.SayHi();
Boop.SayHi();
Console.ReadLine();
}
}
static class Boop
{
static Boop()
{
Console.WriteLine("Hi incoming ...");
}
public static void SayHi()
{
Console.WriteLine("Hi there!");
}
}
Output:
Press enter
// after pressing enter
Hi incoming ...
Hi there!
Hi there!

Here's the actual order in which things go down:
Start of Main
Start of the static MyClass constructor
End of the static MyClass constructor
Start of MyMethod
End of Main

Or you could step through in the debugger.

Static initialization guarantees singleton thread safety? (C#) [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is the C# static constructor thread safe?
Jon Skeet's excellent article at http://csharpindepth.com/Articles/General/Singleton.aspx and other articles I've read make it clear that that double-check locking doesn't work in both C# and Java unless one explicitly marks the instance as "volatile." If you don't, the check of comparing it to null could possibly return false even though the instance constructor hasn't finished running. In Mr. Skeet's third sample, he states this clearly: "The Java memory model doesn't ensure that the constructor completes before the reference to the new object is assigned to instance. The Java memory model underwent a reworking for version 1.5, but double-check locking is still broken after this without a volatile variable (as in C#)"
However, most everyone agrees (including Mr. Skeet, in samples four and five in his article), that the use of static initialization is a simple way to get a threadsafe singleton instance. He states that "static constructors in C# are specified to execute only when an instance of the class is created or a static member is referenced, and to execute only once per AppDomain."
That makes sense, but what seems to be missing is the guarantee that the reference to the new object is assigned only after the constructor completes - otherwise we'd get the same kind of issue that makes double-check locking fail unless you mark the instance as volatile. Is there a guarantee that, when using static initialization to call the instance constructor (as opposed to calling the instance constructor from a property's get{}, like we do with double-check locking), that the constructor will fully complete before any other thread can get a reference to the object?
Thanks!

that the constructor will fully complete before any other thread can get a reference to the object?
The static initializer will be invoked once only (by the system, at least) per AppDomain, and in a synchronized way, taking "beforefieldinit" into account. So assuming you don't do anything bizarre, any static fields assigned in the static initializer should be OK; any other attempts to use the static field should get held (blocked) behind the static constructor.
the reference to the new object is assigned only after the constructor completes
It happens when it happens. Any static field initializers happen before what you typically think of as the constructor, for example. But since other threads are blocked, this shouldn't be an issue.
However:
if your static initializer itself passes a reference outside (by calling a method with the reference as an argument (including "arg0"), then all bets are off
if you use reflection to invoke the static constructor (yes, you can do this), crazyness often follows

Yes; the guarantee is in the statement that it will only execute once per AppDomain.
It could only be unsafe if it could execute more than once; as stated, it can't, so all is well :)