Диспетчер WPF.Invoke 'завис'

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

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

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

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

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

 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 здесь, однако я обнаружил, что не получаю обновления пользовательского интерфейса, когда выполняю этот асинхронный режим. К сожалению, когда я делаю это синхронно, я получаю состояние тупика ...

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

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

Я знаю, что это старый поток, но вот другое решение.

Я только что исправил похожую проблему. Мой диспетчер работал нормально, так что ...

Мне пришлось показать ОКНО ОТЛАДКИ -> ПОТОК, чтобы идентифицировать все потоки, которые где угодно выполняют мой код.

Проверяя каждый из потоков, я быстро видел, какой поток вызвал тупик.

Это было несколько потоков, объединяющих оператор 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--;
    }
}

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

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

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

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

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

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

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

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