Question

I haven’t had any issues using the same lock for multiple methods so far, but I’m wondering if the following code might actually have issues (performance?) that I’m not aware of:

private static readonly object lockObj = new object();

public int GetValue1(int index)
{
    lock(lockObj)
    {
        // Collection 1 read and/or write
    }
}

public int GetValue2(int index)
{
    lock(lockObj)
    {
        // Collection 2 read and/or write
    }
}

public int GetValue3(int index)
{
    lock(lockObj)
    {
        // Collection 3 read and/or write
    }
}

The 3 methods and the collections are not related in anyway.

In addition, will it be a problem if this lockObj is also used by a singleton (in Instance property) ?

Edit: To clarify my question on using the same lock object in a Singleton class:

private static readonly object SyncObject = new object();

public static MySingleton Instance
{
    get
    {
        lock (SyncObject)
        {
          if (_instance == null)
          {
              _instance = new MySingleton();
          }
        }
        return _instance;
    }
}

public int MyMethod()
{
      lock (SyncObject)
      {
           // Read or write
      }  
}

Will this cause issues?

Answer 1

If the methods are unrelated as you state, then use a different lock for each one; otherwise it’s inefficient (since there’s no reason for different methods to lock on the same object, as they could safely execute concurrently).

Also, it seems that these are instance methods locking on a static object — was that intended? I have a feeling that’s a bug; instance methods should (usually) only lock on instance fields.

Regarding the Singleton design pattern:

While locking can be safe for those, better practice is doing a delayed initialization of a field like this:

private static object sharedInstance;
public static object SharedInstance
{
     get
     {
          if (sharedInstance == null)
              Interlocked.CompareExchange(ref sharedInstance, new object(), null);
          return sharedInstance;
     }
}

This way it’s a little bit faster (both because interlocked methods are faster, and because the initialization is delayed), but still thread-safe.