WPF Dispatcher.Invoke 'hanging'

Question

У меня есть несколько сложное приложение WPF, которое, кажется, «висит» или застревает в вызове Wait при попытке использовать диспетчера для вызова вызова в потоке пользовательского интерфейса.

Общий процесс:

1. Обрабатывать событие щелчка на кнопке
2. Создать новую тему (STA), который: создает новый экземпляр ведущего и пользовательского интерфейса, а затем вызывает метод Disconnect
3. Disconnect затем устанавливает свойство на UI называется Имя
4. инкубатор для имени затем использует следующий код для установки свойства:

    if(this.Dispatcher.Thread != Thread.CurrentThread) 
    { 
     this.Dispatcher.Invoke(DispatcherPriority.Normal, (ThreadStart)delegate{ 
      this.Name = value; // Call same setter, but on the UI thread 
     }); 
     return; 
    } 

    SetValue(nameProperty, value); // I have also tried a member variable and setting the textbox.text property directly. 

Моя проблема заключается в том, что когда диспетчер вызова метод называется он подвисает каждый раз, и CallStack указывает, что его во сне, ждать или присоединиться в рамках реализации Invoke.

Итак, есть ли что-то, что я делаю неправильно, что у меня отсутствует, очевидно или нет, или есть лучший способ обратиться к потоку пользовательского интерфейса, чтобы установить это свойство (и другие)?

Edit: Решение было назвать System.Windows.Threading.Dispatcher.Run() в конце нити делегата (например, когда работа выполняется) - Спасибо всем, кто помог.

Answer 1

Вы говорите, что вы создаете новый поток STA, является диспетчером в этом новом потоке?

Я получаю от «this.Dispatcher.Thread! = Thread.CurrentThread», что вы ожидаете, что это будет другой диспетчер. Убедитесь, что он работает, иначе он не будет обрабатывать свою очередь.

Answer 2

Invoke является синхронным - вы хотите Dispatcher.BeginInvoke. Кроме того, я считаю, что ваш образец кода должен перемещать «SetValue» внутри оператора «else».

Answer 3

Это звучит как тупик; это обычно случается, если поток, вызывающий .Invoke, уже содержит блокировку/mutex/etc, которую должен выполнить поток пользовательского интерфейса, чтобы завершить его работу. Самый простой подход - использовать BeginInvoke вместо этого: таким образом, текущий поток может продолжать работать, и он (предположительно) освободит блокировку в ближайшее время, позволяя пользовательскому интерфейсу реализовать его. В качестве альтернативы, если вы можете идентифицировать блокировку нарушения, вы можете намеренно отпустить ее на время.

Answer 4

У меня аналогичная проблема, и пока я еще не уверен, что ответ, я думаю, что ваш

if(this.Dispatcher.Thread != Thread.CurrentThread) 
{ 
    this.Dispatcher.Invoke(DispatcherPriority.Normal, (ThreadStart)delegate{ 
     this.Name = value; // Call same setter, but on the UI thread 
    }); 
    return; 
} 

следует заменить

if(this.Dispatcher.CheckAccess()) 
{ 
    this.Dispatcher.Invoke(DispatcherPriority.Normal, (ThreadStart)delegate{ 
     this.Name = value; // Call same setter, but on the UI thread 
    }); 
    return; 
} 

CheckAccess не покажет в Intellisense, но он существует и предназначен для этой цели. Кроме того, я согласен с тем, что в общем вы хотите, чтобы BeginInvoke здесь, однако я обнаружил, что я не получаю обновления пользовательского интерфейса, когда я делаю это асинхронное. К сожалению, когда я делаю это синхронно, я получаю условие взаимоблокировки ...

Answer 5

Я думаю, вы имеете в виду, если (! This.Dispatcher.CheckAccess())

Я также адресности зависание с Invoke, или если я могу BeginInvoke мой делегат не вызывается - кажется, делает все по книге :-(

Answer 6

Я знаю, что это старая нить, но вот еще одно решения

я просто исправил аналогичную проблему Моей диспетчерская работала отлично, так что ...

Я должен был показать DEBUG -..> нИТКИ ОКНА определить все потоки, выполняются мой код в любом месте.

c c щекочу каждого из нитей, я быстро увидел, какая нить вызвала тупик.

Это было несколько потоков, объединяющих инструкцию lock (locker) { ... } и звонки на Dispatcher.Invoke().

В моем случае я мог бы просто сменить конкретный оператор lock (locker) { ... } и заменить его на Interlocked.Increment(ref lockCounter).

Это решило мою проблему, потому что тупика избегали.

void SynchronizedMethodExample() { 

    /* synchronize access to this method */ 
    if (Interlocked.Increment(ref _lockCounter) != 1) { return; } 

    try { 
    ... 
    } 
    finally { 
     _mandatoryCounter--; 
    } 
} 

Answer 7

Я думаю, что это лучше показано кодом. Рассмотрим такой сценарий:

Поток А делает это:

lock (someObject) 
{ 
    // Do one thing. 
    someDispatcher.Invoke(() => 
    { 
     // Do something else. 
    } 
} 

Thread B делает это:

someDispatcher.Invoke(() => 
{ 
    lock (someObject) 
    { 
     // Do something. 
    } 
} 

Все может показаться хорошо и денди, на первый взгляд, но это не так. Это приведет к тупиковой ситуации. Диспетчеры похожи на очереди для потока, и, когда они имеют дело с такими взаимоблокировками, важно подумать о них так: «Какая предыдущая отправка могла замять мою очередь?». Тема А войдет в ... и отправится под замок. Но, что, если поток B входит в момент времени, когда Thread A находится в коде, отмеченном «Сделать одну вещь»? Ну ...

• Резьба A имеет блокировку на someObject и запускает некоторый код.
• Thread B теперь отправляет сообщения, и диспетчер попытается получить блокировку на someObject, забив ваш диспетчер, так как Thread A уже имеет эту блокировку.
• Резьба A затем будет стоять в очереди на другой пункт отправки. Этот элемент никогда не будет запущен, потому что ваш диспетчер никогда не завершит обработку вашего предыдущего запроса; его уже застряли.

У вас теперь есть прекрасный тупик.