Question

How come this isn’t working?

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"));
}

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?

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.

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.

Answer 1

Two part answer:

1. 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.

2. 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).