0

我正在开发一个项目,其中所有 DB 逻辑(读取和写入)都包含以下内容:

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

我去查找了这个 DbRun 方法,发现了这个:

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
}

我的问题是;这与一般lock { /* code here */ }构造相比如何?

4

1 回答 1

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.

于 2012-07-06T06:19:08.033 回答