Perché è responsabilità del chiamante garantire la sicurezza dei thread nella programmazione della GUI?

Ho visto, in molti luoghi, che è saggezza canonica ¹ che è responsabilità del chiamante assicurarsi di essere sul thread dell'interfaccia utente durante l'aggiornamento dei componenti dell'interfaccia utente (in particolare, in Java Swing, che si è sul thread di invio eventi ) .

Perché è così? Il thread di invio eventi è una preoccupazione della vista in MVC / MVP / MVVM; per gestirlo ovunque ma la vista crea un accoppiamento stretto tra l'implementazione della vista e il modello di threading dell'implementazione di quella vista.

In particolare, supponiamo che io abbia un'applicazione progettata MVC che utilizza Swing. Se il chiamante è responsabile dell'aggiornamento dei componenti sul thread di invio eventi, quindi se provo a scambiare la mia implementazione Swing View per un'implementazione JavaFX, devo invece modificare tutto il codice Presenter / Controller per utilizzare invece il thread dell'applicazione JavaFX .

Quindi, suppongo di avere due domande:

1. Perché è responsabilità del chiamante garantire la sicurezza del thread dei componenti dell'interfaccia utente? Dov'è il difetto nel mio ragionamento sopra?
2. Come posso progettare la mia applicazione in modo da avere un accoppiamento libero di questi problemi di sicurezza della filettatura, ma allo stesso tempo essere adeguatamente sicuro per la filettatura?

Consentitemi di aggiungere un po 'di codice Java MCVE per illustrare ciò che intendo per "responsabile del chiamante" (ci sono alcune altre buone pratiche che non sto facendo, ma sto cercando di essere il più minimale possibile):

Il chiamante è responsabile:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}

public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

Visualizza essere responsabile:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}

public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

_{1: L'autore di quel post ha il punteggio più alto in Swing su Stack Overflow. Lo dice dappertutto e ho anche visto che è responsabilità del chiamante anche in altri posti.}

Verso la fine del suo saggio sui sogni fallito , Graham Hamilton (un grande architetto Java) menziona se gli sviluppatori "devono preservare l'equivalenza con un modello di coda di eventi, dovranno seguire varie regole non ovvie" e avere un visibile ed esplicito modello di coda eventi "sembra aiutare le persone a seguire il modello in modo più affidabile e quindi a costruire programmi GUI che funzionano in modo affidabile".

In altre parole, se si tenta di posizionare una facciata multithread in cima a un modello di coda eventi, l'astrazione a volte cola in modi non ovvi che sono estremamente difficili da eseguire il debug. Sembra che funzionerà sulla carta, ma finisce per cadere a pezzi in produzione.

L'aggiunta di piccoli wrapper attorno a singoli componenti probabilmente non sarà problematico, come aggiornare una barra di avanzamento da un thread di lavoro. Se provi a fare qualcosa di più complesso che richiede più blocchi, inizia a diventare davvero difficile ragionare su come interagiscono il livello multithread e il livello coda eventi.

Si noti che questo tipo di problemi sono universali per tutti i toolkit della GUI. Presumere che un modello di invio di eventi nel tuo presentatore / controller non ti stia legando strettamente a un solo modello di concorrenza del toolkit GUI specifico, ma ti sta abbinando a tutti loro . L'interfaccia di accodamento degli eventi non dovrebbe essere così difficile da astrarre.

Perché rendere sicuro il thread lib della GUI è un grosso mal di testa e un collo di bottiglia.

Il flusso di controllo nelle GUI spesso va in 2 direzioni dalla coda degli eventi alla finestra principale ai widget gui e dal codice dell'applicazione al widget propagato fino alla finestra principale.

È difficile definire una strategia di blocco che non blocchi la finestra di root (causerà molte contese) . Il blocco dal basso verso l'alto mentre un altro thread sta bloccando dall'alto verso il basso è un ottimo modo per ottenere un deadlock istantaneo.

E verificare se il thread corrente è il thread della GUI ogni volta che è costoso e può causare confusione su ciò che sta realmente accadendo con la GUI, specialmente quando si sta eseguendo una sequenza di scrittura di aggiornamento di lettura. Ciò deve avere un blocco sui dati per evitare le gare.

Il threadedness (in un modello di memoria condivisa) è una proprietà che tende a sfidare gli sforzi di astrazione. Un semplice esempio è un Settipo: mentre Contains(..)ed Add(...)ed Update(...)è un'API perfettamente valida in uno scenario a thread singolo, lo scenario a thread multipli richiede un AddOrUpdate.

Lo stesso vale per l'interfaccia utente: se si desidera visualizzare un elenco di elementi con un conteggio degli elementi in cima all'elenco, è necessario aggiornare entrambi su ogni modifica.

1. Il toolkit non può risolvere questo problema poiché il blocco non assicura che l'ordine delle operazioni rimanga corretto.
2. La vista può risolvere il problema, ma solo se si consente alla regola aziendale che il numero in cima all'elenco debba corrispondere al numero di elementi nell'elenco e aggiornare l'elenco solo attraverso la vista. Non esattamente quello che dovrebbe essere MVC.
3. Il relatore può risolverlo, ma deve sapere che la vista ha esigenze particolari in merito al threading.
4. Un'altra opzione è rappresentata dal collegamento a un modello con capacità multi-threading. Ma ciò complica il modello con cose che dovrebbero essere preoccupazioni dell'interfaccia utente.

Nessuno di questi sembra davvero allettante. Rendere il presentatore responsabile della gestione del threading è consigliato non perché è buono, ma perché funziona e le alternative sono peggiori.

Qualche tempo fa ho letto un ottimo blog che discute di questo problema (menzionato da Karl Bielefeldt), quello che dice in sostanza è che è molto pericoloso provare a rendere sicuro il thread del kit UI, poiché introduce possibili deadlock e dipende da come è implementato, condizioni di gara nel quadro.

C'è anche una considerazione delle prestazioni. Non molto ora, ma quando Swing è stato rilasciato per la prima volta è stato fortemente criticato per le sue prestazioni (è stato un male), ma non è stata davvero colpa di Swing, è stata la mancanza di conoscenza delle persone su come usarlo.

SWT applica il concetto di sicurezza del thread generando eccezioni se lo violate, non è carino, ma almeno ne siete consapevoli.

Se osservi il processo di verniciatura, ad esempio, l'ordine in cui gli elementi sono dipinti è molto importante. Non vuoi che il dipinto di un componente abbia un effetto collaterale su qualsiasi altra parte dello schermo. Immagina di poter aggiornare la proprietà text di un'etichetta, ma è stata dipinta da due thread diversi, potresti finire con un output danneggiato. Quindi tutta la verniciatura viene eseguita all'interno di un singolo filo, normalmente basato sull'ordine dei requisiti / richieste (ma a volte condensato per ridurre il numero di cicli di verniciatura fisici effettivi)

Dici di cambiare da Swing a JavaFX, ma avresti questo problema con praticamente qualsiasi framework dell'interfaccia utente (non solo client spessi, ma anche web), Swing sembra proprio essere quello che evidenzia il problema.

È possibile progettare un livello intermedio (un controller di un controller?) Il cui compito è garantire che le chiamate all'interfaccia utente siano sincronizzate correttamente. È impossibile sapere esattamente come potresti progettare le parti non UI della tua API dal punto di vista dell'API UI e la maggior parte degli sviluppatori si lamenterebbe che qualsiasi protezione thread implementata nell'API UI fosse restrittiva o non soddisfaceva le loro esigenze. Meglio consentirti di decidere come risolvere questo problema, in base alle tue esigenze

Uno dei maggiori problemi che devi considerare è la capacità di giustificare un determinato ordine di eventi, sulla base di input noti. Ad esempio, se l'utente ridimensiona la finestra, il modello Coda eventi garantisce che si verifichi un determinato ordine di eventi, questo potrebbe sembrare semplice, ma se la coda consentiva agli eventi di essere attivati ​​da altri thread, non è più possibile garantire l'ordine in quali eventi potrebbero verificarsi (una condizione di gara) e all'improvviso devi iniziare a preoccuparti di diversi stati e non fare una cosa finché non succede qualcos'altro e inizi a dover condividere bandiere di stato in giro e finisci con gli spaghetti.

Ok, potresti risolverlo avendo una specie di coda che ordina gli eventi in base al momento in cui sono stati emessi, ma non è quello che già abbiamo? Inoltre, non puoi ancora garantire che il thread B genererà i suoi eventi DOPO il thread A

Il motivo principale per cui le persone si arrabbiano nel dover pensare al proprio codice è perché sono costretti a pensare al proprio codice / design. "Perché non può essere più semplice?" Non può essere più semplice, perché non è un problema semplice.

Ricordo quando è stata rilasciata la PS3 e Sony parlava del processore Cell ed è in grado di eseguire linee separate di logiche, decodificare audio, video, caricare e risolvere i dati del modello. Uno sviluppatore di giochi ha chiesto: "È tutto fantastico, ma come si sincronizzano i flussi?"

Il problema di cui parlava lo sviluppatore era, ad un certo punto, che tutti quei flussi separati avrebbero dovuto essere sincronizzati su un singolo tubo per l'output. Il povero presentatore si strinse semplicemente nelle spalle perché non era un problema a loro familiare. Ovviamente, hanno avuto soluzioni per risolvere questo problema ora, ma al momento è divertente.

I computer moderni stanno ricevendo contemporaneamente molti input da molti luoghi diversi, tutti gli input devono essere elaborati e consegnati all'utente in remoto, il che non interferisce con la presentazione di altre informazioni, quindi è un problema complesso, senza un'unica soluzione semplice.

Ora, avendo la possibilità di cambiare framework, non è una cosa facile da progettare, MA prendi MVC per un momento, MVC può essere multistrato, cioè potresti avere un MVC che si occupa direttamente della gestione del framework UI, tu potrebbe quindi concludere che, ancora una volta, in un MVC di livello superiore che si occupa delle interazioni con altri framework (potenzialmente multi threaded), sarebbe responsabilità di questo layer determinare come viene notificato / aggiornato il layer MVC inferiore.

Dovresti quindi utilizzare la codifica per interfacciare i modelli di progettazione e i modelli di fabbrica o di costruzione per costruire questi diversi livelli. Ciò significa che i framework multithread vengono disaccoppiati dal livello dell'interfaccia utente attraverso l'uso di un livello intermedio, come idea.