Are static methods thread safe

Solution 1:

Static methods aren't inherently thread-safe. They're treated no differently by the CLR than instance methods. The difference is that one should generally try to make them thread-safe. (I can't think of any .NET BCL static methods which aren't thread-safe.) Instance methods are often not thread-safe because the typical pattern is to create an object and use it repeatedly from one thread, and if it does have to be used from multiple threads, the co-ordination involved includes making sure that the object is used safely. In very many cases that's more appropriate to do in the co-ordinating code than in the object itself. (Usually you want to make whole sequences of operations effectively atomic - something which can't be done within the object.)

Your Timer class is most definitely not thread-safe: two threads can stomp on each other's data with ease, and there's nothing to stop a thread from using "stale" data when calculating the duration.

Use the Stopwatch class instead - that's what it's there for. Admittedly if you want to use one instance from multiple threads you'll need to take the normal steps to ensure safety, but you'll be in a much better position in general. Admittedly Stopwatch is far from perfect too - see this question and the comment below for more details - but it is at least what the type is designed for. (Who knows, it may be fixed some time...)

Solution 2:

There is a good discussion here that focuses more on the mechanisms and reasons for why your example is not thread-safe.

To summarize, first, your static variables will be shared. If you could make them local variables, even though they are local to a static method, they would still get their own stack frame, and thus, be thread-safe. Also, if you otherwise protect your static variables (ie, locks and/or other multi-threaded programming techniques mentioned by others in this thread) you could also make your sample static class thread-safe.

Second, because your example does not take in external variable instances which you modify or whose state might get acted upon by another thread, your example is thread-safe in that regard as well.

Solution 3:

Your timer class is definitely not thread-safe. You should create a normal class and instantiate it every time you need to measure the time:

Timer timer = new Timer();

timer.Start();
//...
timer.Stop();

decimal duration = timer.Duration();

Better still, there is a built-in .NET class that does exactly that:

Stopwatch sw = Stopwatch.StartNew();

sw.Stop();

TimeSpan duration = sw.Elapsed;

Solution 4:

Yes, you're right, the static members / accessors on this class will cause them to be overwritten by different users.

This is why you have instances and non-static members.