为什么这是不工作？

private static object Lock_HandleError = new object();
public static void HandleError(Exception ex)
{
    lock( Lock_HandleError )
    {
        //IF the UI is processing a visual tree event (such as IsVisibleChanged), it throws an exception when showing a MessageBox as described here: http://social.msdn.microsoft.com/forums/en-US/wpf/thread/44962927-006e-4629-9aa3-100357861442
        //The solution is to dispatch and queue the MessageBox. We must use BeginInvoke because dispatcher processing is suspended in such cases.
        Dispatcher.CurrentDispatcher.BeginInvoke((Action)delegate()
        {
            lock( Lock_HandleError )
            {
                Dispatcher.CurrentDispatcher.BeginInvoke((Action)delegate(){ 
                    HandleError(new Exception("testing purposes only")); 
                }, DispatcherPriority.Background);

                MessageBox.Show(ex.Message, "Application Error", MessageBoxButton.OK, MessageBoxImage.Error);
                //This point is not reached until the user clicks "OK"
            }
        }, DispatcherPriority.Background);
    }
}

public void main()
{
    HandleError(new Exception("The first error"));
}

以上code预期的行为是将出现一次一个错误信息，而当用户点击确定后，在 Lock_HandleError 对象将得到派出线程释放，以及的HandleError下一个电话可以继续 - 但我得到的错误消息的无限级联而没有得到击中OK

The expected behaviour of the above code is that one error message will appear at a time, and when the user clicks "OK", the on the Lock_HandleError object will get released from the dispatched thread, and the next call to HandleError can proceed - but what I'm getting is an infinite cascade of error messages without ever getting to hit "OK".

为什么没有这个锁的工作？

Why isn't this lock working?

通过在每个锁声明的进入和退出设置断点，我可以清楚地看到，委托调用锁（）和调度的一个新的呼叫的HandleError 再一次，然后暂停在消息框，以等待用户输入。

By setting breakpoints at the entry and exit of each lock statement, I can clearly see that the delegate is calling lock() and dispatching the a new call to "HandleError" again and then pausing on MessageBox to wait for user input.

与此同时，在另一个线程分派调用的HandleError获取运行 - 但不是在像它应该，它只是通过它爆破锁（）语句等，即使在MessageBox代表清楚地放置一个锁，尚未公布吧。

Meanwhile, in another thread, that dispatched call to HandleError gets run - but instead of waiting at the lock() statement like it should, it's just blasting through it even though the MessageBox delegate clearly placed a lock and has not yet released it.

推荐答案

二部分的答案：

记者了解到，锁重入。当一个线程已经持有对象上的锁，该线程可以一次又一次地采取相同的锁不阻塞。

Understand that locks are re-entrant. When a thread already holds a lock on an object, that thread can take the same lock again and again without blocking.

当第一个消息框起来，UI线程仍在抽水消息，因此后续的（递归）调用的HandleError 正在处理的UI线程（其中，因为它已经持有锁，可以重新输入）。

While the first MessageBox is up, the UI thread is still pumping messages, so subsequent (recursive) calls to HandleError are being processed on the UI thread (which, because it already holds the lock, can re-enter it).