Il multithreading è appropriato per l'impostazione di più finestre nella stessa applicazione?

2

Attualmente sto lavorando con un'applicazione Qt che tenta di utilizzare il multi-threading per realizzare due task

  • Impedire che il loop eventi del thread principale venga bloccato
  • Per aumentare l'efficienza di calcolo

Penseresti che sia una buona idea, ma risulta che potrebbe essere inefficiente. In Qt, il client non è autorizzato a creare un'istanza di una sottoclasse QWidget solo nel thread principale .

Il codice che ho visto finora sembra davvero disordinato. Il programma ha un "thread esecutivo", in altre parole un thread in background che gestisce la richiesta dell'utente (es. Clic del pulsante per un nuovo pannello gui), e ovviamente ci sono altri 3 thread (networking, elaborazione di script e ofcourse il thread principale)

L'installazione è abbastanza funky, l'evento action (es. Clic pulsante) viene segnalato al thread esecutivo, che quindi invia un funtore al thread principale per istanziare l'utente richiesto pannello gui.

Quanto sopra descritto non ha senso. Immagino che i progettisti originali fossero preoccupati del fatto che il thread fosse bloccato, ma ciò non avrebbe dovuto importare. Indipendentemente da quale thread è stato istanziato, finisce comunque nel thread principale, e comunque lo blocca.

Questa potrebbe non essere la scelta di design migliore, o è? Non sono sicuro, forse c'è qualcuno con più esperienza che può far luce su questo. Personalmente ritengo sia preferibile lasciare che un thread gestisca tutte le interazioni dell'utente, e qualsiasi elaborazione utente intensiva dovrebbe essere sottoposta a thread.

Le altre parti filettate hanno senso, avendo un thread separato per l'elaborazione degli script, in realtà la rete potrebbe aumentare l'efficienza, pur non bloccando il ciclo degli eventi principale in modo che la GUI possa rimanere interattiva.

Qualcuno potrebbe anche approfondire quando il multithreading è una buona scelta nella GUI, e in circostanze normali?

Grazie

    
posta Anonymous 09.03.2012 - 22:38
fonte

2 risposte

1

In genere utilizzo i thread per il lavoro visualizzato da una GUI, non per la gestione della GUI stessa. Altrimenti tutti i tipi di problemi come quello che hai qui appaiono.

Questo ti rendi conto in questa citazione "Personalmente ritengo sia preferibile lasciare che un thread gestisca tutte le interazioni dell'utente, e qualsiasi elaborazione utente intensiva dovrebbe essere sottoposta a thread." e credo che sia il modo in cui dovresti prendere questo.

Il thread della GUI utilizzerà i proxy il cui compito è quello di mediare tra le informazioni della GUI e i risultati asincroni provenienti dai thread dei lavoratori. Il tuo proxy può immediatamente creare gli elementi della GUI fornendo al contempo una visualizzazione temporanea di "working ..." o qualcosa di simile in attesa del thread di lavoro che rappresenta per finire e passare i dati.

Non ho una risposta pratica a threading GUI, sembra un problema complesso e non ho esperienza con un sistema del genere.

    
risposta data 10.03.2012 - 00:59
fonte
1

Also could some one also elaborate on when Multithreading is a good choice in GUI, and in regular circumstances?

Nelle applicazioni di borsa (e altre applicazioni in tempo reale) potresti aver bisogno di più di 1 discussione. Hai 1 thread per l'input dell'utente, l'output e un altro che aggiorna i nastri di scorrimento o le barre di avanzamento sulla GUI e probabilmente un terzo che aggiorna i grafici grafici con i dati in streaming. Tuttavia, suppongo che non sia una pratica comune avere più di 1 thread per la GUI come suggerisce questo post: stovf-threading .

    
risposta data 10.03.2012 - 01:06
fonte

Leggi altre domande sui tag