Question

I’m working on a project where all DB-logic (reading and writing) are surrounded with the following:

using(Util.DbRun ()) {
    // Code here
}

And I went to look up this DbRun method and found this:

static readonly object dbWait = new object();
static public IDisposable DbRun ()
{
    Monitor.Enter (dbWait);
    return new Disposable (() => Monitor.Exit(dbWait));
}
class Disposable : IDisposable
{
    private Action action;
    private volatile bool disposed = false;
    public Disposable (Action action)
    {
        if (action == null)
            throw new ArgumentNullException ("action can't be null");
        this.action = action;
    }

    #region IDisposable implementation
    public void Dispose ()
    {
        bool run = false;
        if (!disposed) {
            lock (this) {
                if (!disposed) {
                    run = true;
                    disposed = true;
                }
            }
        }
        if (run)
            action ();
    }
    #endregion
}

And my question is; how does that compare to a general lock { /* code here */ } construct?

Answer 1

Well, that’s extra code to maintain, and a lot of extra objects for GC to handle (although most of them will die in gen-0, so probably not critical), and a lot of extra lock-handles (which could be mitigated by using Interlocked instead of a lock(this) in the dispose).

It also doesn’t quite handle the very unlikely edge case that caused the introduction of the Monitor.Enter(object, ref bool) usage in the current compiler, described here, although that could probably be added.

My biggest question, though, would be: why? what problem is it solving? what is it doing better to justify existence?

If I wanted to do that for a valid reason, then personally I would do away with the delegate usage, and write a custom, implementation-specific disposable object. The delegate is unnecessary complication.

Also: static locks are not always what you want. I would make it an instance and simply make that instance available to where-ever needed it. However… the same approach can be used with lock, much more simply.