.net - 从 Monitor 所有者以外的另一个线程释放锁

Question

我在代码中有一个关键部分，它由两个函数调用分隔，比如 Start() 和 End()。他们使用 Monitor 在执行期间阻塞其他线程。现在我的问题是，如果某个线程出于某种原因没有调用 End()，我的整个过程就会遇到麻烦，因为每个线程都在等待这个 Monitor 得到发布。

当然我可以使用带超时的TryEnter这样我就不会永远等待，但这不会释放阻塞的Monitor，所以我的程序会进入这个从此时开始每次超时。

如果给定超时结束，是否有办法从另一个线程释放阻塞的 Monitor？

void Start(){ Monitor.Enter(obj); }

void End(){ Monitor.Exit(obj); }

编辑:我们通过 com interop 调用 Excel，我们不能确定 Excel 进程将始终按预期工作。请注意，这是一个 Web 应用程序，因此未能处理这种情况是致命的。 Start()是第一次调用，请求是调用一个excel函数，End()是在Request结束时调用。总是有可能 excel 进程开始挂起。

编辑 2:我现在想把 ent lock 的所有者存储在一个变量中，在死锁时我可以终止这个线程。这不会释放锁吗？

                        if (Monitor.TryEnter(excelLocker, 10000) == false)
                        {
                            excelOwner.Abort();
                            excelOwner = null;
                        }
                        else
                        {
                            excelOwner = Thread.CurrentThread;
                        }

Answer 1

唯一可以释放锁的线程是拥有锁的线程。所以不，你不能直接从另一个线程“解除阻塞”监视器 - 这在设计上是不可能的。如果您能够做到这一点，其他线程将能够通过在实际上并不拥有锁时释放锁来覆盖锁的语义。

我很好奇你为什么不使用 lock阻止 Enter和 Exit得到保证，而不是使用 Monitor直接。

更新

阅读您的评论后，我强烈建议组织您的代码，以便您可以本地化锁定，而不是根据请求开始和请求结束。如果您使用 lock您仍然可以序列化访问 Excel，但您可以保证 Enter 和 Exit被调用。

仅供引用 lock是 Monitor在幕后。

    lock(_syncObj)
    {
        //Do stuff
    }

    //Is equivalent to

    Monitor.Enter(_syncObj);
    try
    {
        //Do stuff
    }
    finally
    {
        Monitor.Exit(_syncObj);
    } 

使用 lock您可以按如下方式本地化您的 Excel 锁定:

    //Client code
    ExcelUtil.DoStuff("bling")

    //...

    //Util class manages call to Excel and locking.
    public static class ExcelUtil
    {
        private static readonly object SyncObj = new object();

        public static void DoStuff(string someParam)
        {
            //Guaranteed locking and unlocking even if an exception occurs
            lock (SyncObj)
            {
                DoSomeStuffWithExcelFuncA();
                DoSomeStuffWithExcelFuncB();
            }
        }

        private static void DoSomeStuffWithExcelFuncA()
        {
            //...
        }

        private static void DoSomeStuffWithExcelFuncB()
        {
            //...
        }
    }

顺便说一句，您为什么要锁定对 Excel 的访问权限？我猜您正在为您的 ASP.Net 应用程序使用 Excel 自动化服务器端。除非事情发生重大变化，否则这至少在几年前总是很麻烦。如果你取出一把锁，Excel 挂起，你就完蛋了。可以使用第 3 方解决方案来代替 Excel 自动化。也许较新版本的 Excel 喜欢以这种方式使用？

您的模式似乎序列化所有请求，以便在任何时候只能执行一个(基于 Excel 的)请求 - 这似乎不是很理想。