锁定线程的正确方法是什么？

Question

In my MVC 3 C# application I have some static object that I want to be available to one request at a time. Access to it is only through methods, but I want the lock to be kept in between calling its methods.

Calls will be done only in a controller, usually there will be one or two locked blocks of code.

At first I wanted to expose some static public object and use it simply like

lock(MyClass.lockObject)
{
 MyClass.doStuff();
 MyClass.doStuff2();
}

, but I find it error prone, as I might forget to lock it somewhere. I wonder if it is a proper way to use Monitor.Enter() in a constructor, and Monitor.Exit() in a Dispose method, and then change my methods to nonstatic? Say, something like:

public class MyClass:IDisposable
{
    static protected object _locker = new object();
    protected bool isDisposed = false;

    public MyClass()
    {
        Monitor.Enter(_locker);
    }

    public void Dispose()
    {
        if (!isDisposed)
        {
            Monitor.Exit(_locker);
            GC.SuppressFinalize(this);
            isDisposed = true;
        }
    }

    ~SPInstances()
    {
        Dispose();
    }

    public void doStuff()
    {
        if(isDisposed) throw new ObjectDisposedException();
        // do stuff here, etc.
    }
}

Then I could use it as:

using(MyClass myinstance = new MyClass())
{
    myInstance.doStuff();
    myInstance.doStuff2();
}

Then, even if I forgot to wrap code in using, it will still lock and there will be some chance that it will get unlocked during garbage collecting...

I'm not proficient in C# and sometimes overlook some aspects, and threading is never easy to debug later on, so I'm wondering if I'm on a good track. Is it a proper way to achieve my goal?

EDIT:

Extending Master Morality idea, would this way be better (I simplified it a bit, as I need only one instance of resource)?

public class MyClass
{
    static protected readonly MyResourceType _myResourceStatic = new MyResourceType();
    static public void DoWork(Action<MyClass> action)
    {
        lock(_myResource)
        {
            action(new MyClass(_myResource));
        }        
    }

    protected MyClass(MyResourceType myResource)
    {
        _myResource = myResource;
    }
    protected readonly _myResource;

    public void DoFirstThing() { ... }
    public void DoSecondThing(){ ... }
}

MyClass.DoWork(x => 
{
    x.DoFirstThing();
    // do unrelated stuff
    x.DoSecondThing();
});

Answer 1

IMHO it's better to lock inside your own methods. That way, another programmer, or yourself later, doesn't have to remember to lock before they call a method, and it's simple enough.

public class MyClass
{
    private static readonly object _gate = new object();

    /* something that can only be accessed by one thread at a time...*/
    private static MyResourceType MyResource = new MyResourceType();

    public void DoSomething()
    {
         lock(_gate)
         {
            /* do something with MyResource, just make sure you
               DO NOT call another method that locks the gate
               i.e. this.DoSomethingElse(), in those situations,
               you can take the logic from DoSomethingElse() and
               toss it in a private method i.e. _DoSomethingElse().
             */
         }
    }

    private void _DoSomethingElse()
    {
        /* do something else */
    }

    public void DoSomethingElse()
    {
         lock(_gate)
         {
             _DoSomethingElse();
         }
     }
}

Later that day...

var myClass = new MyClass();
myClass.DoSomething();

if you want to be able to call multiple methods with a lock, you can do it with a lambda, and to be really safe, wrap it in a helper class.

public class MyClass
{
    public MyResourceType MyResource { get; set; }
    public void DoFirstThing() { ... }
    public void DoSecondThing(){ ... }
}

public class MyClassHelper
{
    private static readonly object _gate = new Object();
    private static MyResourceType MyResource = new MyResourceType();

    private MyClass _myClass = new MyClass();        

    public void DoWork(Action<MyClass> action)
    {
         lock(_gate)
         {
             _myClass.MyResource = MyResource;
             action(_myClass);
             _myClass.MyResource = null;
         }
    }
}

...

var myClassHelper = new MyClassHelper();
myClassHelper.DoWork(x => 
    {
        x.DoFirstThing();
        x.DoSecondThing();
    });

Answer 2

lock is easier and less error prone that using Monitor.Enter and Exit directly.

It's not clear from your example what you're trying to synchronize.

It is not a good idea to Monitor.Enter in a constructor and Exit in Dispose. You will have to handle all exceptions within the c'tor and call Exit if you can't construct the class properly. It doesn't make sense for an instance to be locked--which this essentially means by locking the c'tor. You might want to look at the Synchronized attribute; but I don't think that's really recommended.

Answer 3

Is it critical that requests from other objects upon your static object be executed immediately? You can achieve mutual exclusion through thread isolation if you have your static object maintain a queue that it itself works through. On a call from another object, the requested work is placed on the queue, while in a separate thread the static object is working through the queue (note the need for mutually exclusive access to the queue, though!) performing requests.

You can either have the calling objects block in the method that added the work to the queue until notified by the static object, or provide a callback interface to allow the static object to notify the calling objects that their work is done.

Answer 4

From your example is not exactly clear what you're trying to do. As good programming practice it is better to have each individual method obtain the lock and release it when it is done with the critical section. In your case it will be:

void doStuff()
{
    if(isDisposed) throw new ObjectDisposedException();
    // do stuff here, etc.
    lock(_locker) { 
       // enter critical section here 
    }
    // continue to do other stuff
}

void doStuff2()
{
    if(isDisposed) throw new ObjectDisposedException();
    // do stuff here, etc.
    lock(_locker) { 
       // enter critical section here 
    }
    // continue to do other stuff
}

Now lock is a short-cut version for using the Monitor class. And is actually translated like:

bool getLock = false;
try {
  Monitor.Enter(locker, ref getLock);
  // do stuff here
}
finally {
  if(getLock) {
    Monitor.Exit(locker);
  }
}

This will give you more control over the state of your object & internal representation, as if there something wrong happens you can revert back to the previous state of your object.

Answer 5

If there are not many combinations of calls you could make dostuff and doStuff2 private and place a wrapper function in your class with a lock

static public void doStuffs()
{
    lock (lockObject)
    {
        doStuff();
        doStuff2();
    }
}