WPF Dispatcher.Invoke 'sospeso'

Question

Ho un'applicazione WPF piuttosto complessa che sembra "sospesa" o si blocca in una chiamata di attesa quando si tenta di utilizzare il dispatcher per richiamare una chiamata sul thread dell'interfaccia utente.

Il processo generale è:

1. gestire l'evento clic su un pulsante
2. creare un nuovo thread (STA), che: crea una nuova istanza del presentatore e interfaccia utente, quindi chiama il Disconnect metodo
3. Disconnect imposta poi una proprietà sulla UI chiamato Nome
4. il setter per nome, allora utilizza il seguente codice per impostare la proprietà:

    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. 

Il mio problema è che quando il dispatcher invocare metodo viene chiamato sembra bloccarsi ogni volta, e lo stack di chiamate indica che il suo in un sonno, attendere o partecipare nell'ambito dell'attuazione Invoke.

Quindi, c'è qualcosa che sto facendo male che mi manca, ovvio o no, o c'è un modo migliore di chiamare attraverso il thread dell'interfaccia utente per impostare questa proprietà (e altri)?

Edit: La soluzione fu di chiamare System.Windows.Threading.Dispatcher.Run() alla fine del delegato filo (ad esempio dove veniva eseguito il lavoro) - Grazie a tutti coloro che hanno contribuito.

Answer 1

Si dice che si sta creando un nuovo thread STA, è in esecuzione il dispatcher su questo nuovo thread?

Sto ottenendo da "this.Dispatcher.Thread! = Thread.CurrentThread" che ci si aspetta che sia un dispatcher diverso. Assicurati che sia in esecuzione altrimenti non elaborerà la coda.

Answer 2

Invoke è sincrono - si desidera Dispatcher.BeginInvoke. Inoltre, credo che il tuo esempio di codice dovrebbe spostare il "SetValue" all'interno di un'istruzione "else".

Answer 3

Questo sembra un punto morto; questo normalmente si verifica se il thread chiama .Invoke contiene già un lock/mutex/etc che il thread UI deve completare per funzionare. L'approccio più semplice sarebbe utilizzare BeginInvoke: in questo modo, il thread corrente può continuare a funzionare e (presumibilmente) rilasciare il blocco a breve, consentendo all'interfaccia utente di acquisirlo. In alternativa, se è possibile identificare il blocco offendente, è possibile rilasciarlo deliberatamente per una durata.

Answer 4

Sto avendo un problema simile e mentre io non sono ancora sicuro di quale sia la risposta, penso che la tua

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

dovrebbe essere sostituito da

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

CheckAccess non mostrerà in Intellisense ma è lì e destinato a questo scopo. Inoltre, sono d'accordo sul fatto che in generale tu voglia BeginInvoke qui, tuttavia ho scoperto che non ottengo aggiornamenti dell'interfaccia utente quando eseguo questo async. Sfortunatamente, quando lo faccio in modo sincrono ottengo una condizione di deadlock ...

Answer 5

Penso che intendi se (! Questo.Dispatcher.CheckAccess())

sto anche geting un appendere con Invoke, o se posso BeginInvoke mio delegato non viene chiamato - sembrano fare tutto dal libro :-(

Answer 6

So che questo è un thread vecchio, ma qui è un'altra soluzione

ho appena risolto un problema simile mio dispatcher stava funzionando bene, quindi ...

ho dovuto mostrare il DEBUG -..> fILO FINESTRA per identificare tutti i fili che sto eseguendo il mio codice ovunque.

c controllando ciascuno dei thread, ho visto rapidamente quale thread ha causato il deadlock.

Si trattava di più thread combinando un'istruzione lock (locker) { ... } e chiamate a Dispatcher.Invoke().

Nel mio caso, ho potuto semplicemente modificare una specifica istruzione lock (locker) { ... } e sostituirla con Interlocked.Increment(ref lockCounter).

Questo ha risolto il problema perché il deadlock è stato evitato.

void SynchronizedMethodExample() { 

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

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

Answer 7

Penso che questo sia meglio mostrato con il codice. Consideriamo questo scenario:

Discussione A fa questo:

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

Discussione B fa questo:

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

Tutto potrebbe apparire bene e dandy, a prima vista, ma la sua non. Questo produrrà un deadlock. I dispatcher sono come le code di un thread e, quando si tratta di deadlock come questi, è importante pensarli in questo modo: "Quale dispatch precedente avrebbe potuto bloccare la mia coda?". Il thread A entrerà in ... e verrà inviato sotto una serratura. Ma, cosa succede se il thread B arriva nel momento in cui il thread A è nel codice contrassegnato come "Fai una cosa"? Bene ...

• Il thread A ha il blocco su someObject e sta eseguendo del codice.
• Il thread B ora invia e il dispatcher tenterà di ottenere il blocco su someObject, bloccando il dispatcher poiché il thread A ha già quel blocco.
• Il thread A quindi accoderà un altro elemento di spedizione. Questo oggetto non verrà mai sparato, perché il tuo committente non finirà mai di elaborare la tua richiesta precedente; è già inceppato.

Ora avete una bella situazione di stallo.