We Keep Coding

Are C# static class private fields thread safe?

I have a C# static class accessed from multiple threads. Two questions:
Are my private static fields thread safe when the field is initialized on declaration?
Should I lock when creating private static fields from within static constructor?
Usage of static class from different threads:
class Program
{
static void Main(string[] args)
{
for (int i = 0; i < 100; i++)
{
Task.Run(() =>
{
string name = MyStaticClass.GetValue(9555);
//...
});
}
}
}
Option 1 of static class:
public static class MyStaticClass
{
private static MyClass _myClass = new MyClass();
public static string GetValue(int key)
{
return _myClass.GetValue(key);
}
}
Option 2 of static class:
public static class MyStaticClass
{
private static MyClass _myClass;
private static object _lockObj = new object();
static MyStaticClass()
{
InitMyClass();
}
private static void InitMyClass()
{
if (_myClass == null)
{
lock(_lockObj)
{
if (_myClass == null)
{
_myClass = new MyClass();
}
}
}
}
public static string GetValue(int key)
{
return _myClass.GetValue(key);
}
}
Instance class created from the static class:
public class MyClass
{
private Dictionary<int, Guid> _valuesDict = new Dictionary<int, Guid>();
public MyClass()
{
for (int i = 0; i < 10000; i++)
{
_valuesDict.Add(i, Guid.NewGuid());
}
}
public string GetValue(int key)
{
if (_valuesDict.TryGetValue(key, out Guid value))
{
return value.ToString();
}
return string.Empty;
}
}

Should I lock when initializing private static fields from within static constructor?
Let's not bury the lede here:
Never lock in a static constructor. Static constructors are already locked by the framework so that they run on one thread exactly once.
This is a special case of a more general bit of good advice: never do anything fancy with threads in a static constructor. The fact that static constructors are effectively locked, and that lock can be contested by any code that accesses your type, means that you can very quickly get into deadlocks that you did not expect and are hard to see. I give an example here: https://ericlippert.com/2013/01/31/the-no-lock-deadlock/
If you want lazy initialization, use the Lazy<T> construct; it was written by experts who know how to make it safe.
Are my private static fields thread safe when the field is initialized on declaration?
Thread safety is the preservation of program invariants when program elements are called from multiple threads. You haven't said what your invariants are, so it is impossible to say if your program is "safe".
If the invariant you are worried about is that the static constructor is observed to run before the first static method is executed, or the first instance is created, of a type, C# guarantees that. Of course, if you write crazy code in your static constructor, then crazy things can happen, so again, try to keep your static constructors very simple.

fields of static class are not thread safe by default and should avoid unless it is just for read purpose.
Here down side is "lock" as well, it will create serialized processing in multi threaded environment.
public static class MyStaticClass
{
private static MyClass _myClass;
private static object _lockObj;
static MyStaticClass()
{
_myClass = new MyClass();
_lockObj = new object();
}
public static string GetValue(int key)
{
return _myClass.GetValue(key);
}
public static void SetValue(int key)
{
lock(_lockObj)
{
_myClass.SetValue(key);
}
}
}

Your second version is preferable. You can lock it down a little bit more by making your field readonly:
public static class MyStaticClass
{
private static readonly MyClass _myClass = new MyClass();
public static string GetValue(int key)
{
return _myClass.GetValue(key);
}
}
Your intent appears to be that _myClass is initially set to an instance of MyClass and never set to another. readonly accomplishes that by specifying that it can only be set once, either in a static constructor or by initializing it as above. Not only can another thread not set it, but any attempt to change it will result in a compiler error.
You could omit readonly and just never set _myClass again, but readonly both communicates and enforces your intent.
Here's where it gets trickier: Your reference to an instance of MyClass is thread safe. You don't have to worry about whether various threads will replace it with a different instance (or set it to null), and it will be instantiated before any threads attempt to interact with it.
What this does not do is make MyClass thread safe. Without knowing what it does or how you interact with it, there's no way for me to say what the needs or concerns are.
If that is a concern, one approach is to use a lock to prevent concurrent access that shouldn't occur, exactly as #Mahi1722 demonstrated. I'm including the code from that answer (not to plagiarize, but if anything happens to that answer then this one will refer to an answer that doesn't exist.)
public static class MyStaticClass
{
private static MyClass _myClass = new MyClass();
private static object _lockObj = new object();
public static string GetValue(int key)
{
return _myClass.GetValue(key);
}
public static void SetValue(int key)
{
lock(_lockObj)
{
_myClass.SetValue(key);
}
}
}
Both methods that interact with _myClass lock using _lockObject which means that any execution of either will block while another thread is executing either.
That's a valid approach. Another is to actually make MyClass thread safe, either by using concurrent collections or implementing such locks within that class. That way you don't have to use lock statements in every class that uses an instance of MyClass. You can just use it knowing that it manages that internally.

Both are correct,
but there is no need to lock inside static constructor.
So, i will choose the first option, it is shorter and clearer

Do not lock on objects with weak identity

How can i resolve this reliability issue(Do not lock on objects with weak identity)?
Should i lock it with "object locker = new object();"?
lock (typeof(ObjectCultures))
{
if (!requestCache.Contains(GetCacheKey(objectId, cultureId)))
{
requestCache.Add(GetCacheKey(objectId, cultureId), responseStr);
}
}

Create a new static instance of an object and lock on that:
private static readonly object locker = new object();
lock (locker)
{
....
}
This is on the assumption you are locking inside a static method (due to your use of typeof(T) instead of the this which is also bad practice).
Obviously if you are inside an instance method remove the static from the declaration.
This article by Jon Skeet will help explain why the issue is being flagged in the first place.

You should lock an object not a type. Declare and instance this object in a main scope of your class, for sample:
public class SomeClass
{
private static readonly object _lock = new object();
public void SomeMethod()
{
lock (_lock)
{
// some code
}
}
}
This code will block all thread that are trying to execute this block and make them wait for finish and then execute the next thread.

Effectively, you need to put the lock in a static object reference. An object typed reference should be enough.
public class X
{
private readonly static _syncLock = new object();
public void DoStuff()
{
lock(_syncLock)
{
// Critical section
}
}
}

Exactly how you should lock.. depends on the context, and the bigger picture of code you are trying to write..
What you do want to avoid, is locking on objects of type indicated in the link you already got -
http://msdn.microsoft.com/en-us/library/ms182290.aspx
Do note that the handful of types listed here is not the full list...
• MarshalByRefObject
• ExecutionEngineException
• OutOfMemoryException
• StackOverflowException
• String
• MemberInfo
• ParameterInfo
• Thread
Full list would include instance of any type which is derived directly or indirectly from any of the above mentioned types..
Note that System.Type extends System.Reflection.MemberInfo
http://msdn.microsoft.com/en-us/library/system.type.aspx
And hence the warning, when using lock (typeof(ObjectCultures))

Lock code section in c#

My question may sound like many others here but it has a flavor I didn't find.
I am trying to understand the following logic
A generic object
public class GenericClass
{
public static void DoSomething(Object lockObj)
{
lock(lockObj)
{
// do something here
}
}
}
Class A
internal class A
{
private static _aLock = new Object();
public void Do_A_Thing()
{
GenericClass.DoSomething(_aLock);
}
}
Class B
internal class B
{
private static _bLock = new Object();
public void Do_B_Thing()
{
GenericClass.DoSomething(_bLock);
}
}
I just hope to confirm if my explanation is correct:
If multiple threads of class "A" will attempt simultaneously access code in "genericClass" method "DoSomething", this method will be locked to all but one instance of class "A". But a single instance of class "B" will be able to proceed with execution any time. If class "B" will also have multiple instances execute, they will not interfere with class "A" locks.
Is this correct based on what you see above?

Yes, your description sounds correct. It is perhaps a little unusual to pass the lock object in, but it'll work fine. The only change I would suggest is to make the static fields readonly so you can't accidentally change the value to a different object reference.

Your conclusion is correct but it is not a good practice to pass locked object around. I suggest to put the lock inside class A and B respectively.
I suggest to write:
internal class A
{
private static readonly _aLock = new Object();
public void Do_A_Thing()
{
lock (_aLock)
{
GenericClass.DoSomething();
}
}
}
Do you have a specific reason to put the lock in another class? Maybe you can solve your problem in a different way?
Also keep in mind that in some conditions, maybe it is not your case, you can have a deadlock if class A and B call each other (A->B->A).

Yes, that is correct. The locks in A and the locks in B are completely unaware of each other. The code will only be blocked when there is another thread locking it with the same object as identifier.

If you are using generics, then something like
public class MyGadget<T>
{
static readonly SyncRoot = new object() ;
public T SynchronizedMethod()
{
lock ( SyncRoot )
{
SynchronizedMethodGuts() ;
}
}
}
should do what you want because MyGadget<Foo> and MyGadget<Bar> are different classes: they each have their own, different SyncRoot field.

Singleton Instance

I know there are lot of ways to implement a thread safe singleton pattern like (Double Check Locking , static readonly method, lock method) but i just tried below code
static void Main(string[] args)
{
for (int i = 0; i <= 100; i++)
{
Thread t = new Thread(new ParameterizedThreadStart(doSome));
t.Start(null);
}
Console.ReadLine();
}
private static void doSome(object obj)
{
MyReadOnly obj1 = MyReadOnly.getInstance;
Console.WriteLine(obj1.GetHashCode().ToString());
}
class MyReadOnly
{
private static MyReadOnly instance = new MyReadOnly();
int counter = 0;
// static MyReadOnly()
// {
// } treat is as commented code.
public static MyReadOnly getInstance { get { return instance; } }
private MyReadOnly()
{
Console.WriteLine((++counter).ToString());
}
}
when i see the output of this program , i see just single object created (because of same hashcode)
how to prove that this code is not thread safe?
EDIT
removing static constructor which causes some confusion

That code is thread-safe due to the nature of type initializers in .NET. The type initializer is guaranteed to run exactly once, and if two threads try to run it at the same time, one will do so and the other will block.
See my article on singleton implementation for more details.

This is actually thread-safe code because you are (indirectly) using static constructor to create the instance (And CLR guarantees invocation of static constructor is thread-safe manner on/before access to any other type member).

Performing one time initialization in multithreaded C# programs

Is the snippet below "safe" for performing some initialization once in a multithreaded program?
I'm a bit worried that boxing/unboxing might cause some problem...
private static object initialized = false;
public static void Initialize()
{
lock (initialized)
{
if ((bool)initialized == false)
{
DoInitialization();
initialized = true;
}
}
}
Note that I can't just do the initialization from Main or some other single threaded context.

You are right - that's not going to work because you are reassigning the object you are locking on.
You can do this with two seperate members - an object to lock on that is assigned only once, and then a boolean that you can read or assign to (after you have locked).
You may also want to consider if a singleton would be appropriate here.

Try a double-checked locking.
private static volatile bool initialized = false;
private static object syncObject = new object();
public static void Initialize() {
if (!initialized) {
lock (syncObject) {
if (!initialized) {
DoInitialization();
initialized = true;
}
}
}
}

A few options:
lock on a once-assigned reference-type, as Mark has mentioned.
Initialize on the static-constructor, which is guaranteed to only run once. Con: Hard to control when you want the initialization to occur.
If possible, the Lazy class, which is thread-safe.
All 3 methods can also be used to create Singletons.