[Java] - Swing e Threads

[DNAx86]

In ambiente SWING, quando si crea il JFrame principale,
lo si crea dal main (thread iniziale)
sul thread degli eventi EDT usando: SwingUtilities.invokeLater(...)

La mia domanda è:
dato che il mio programma svolge tutte le funzioni in base alla pressione dei JButton, allora come faccio ad evitare che tutte le funzione chiamate dai JButtons finiscano sul thread degli eventi EDT ?

Pensavo di creare per ogni JButton un thread,
ma cosi diventa estremamente complicato, soprattutto perche ho molti JButton e tutti richiamano algoritmi complicati (e non posso farli gestire dall EDT)

Come posso fare?

PS: Conosco la OOP, ho appena superato l'esame all'università,
ma non è stato spiegato SWING, e i Thread sono stati solo sorvolati.
Il libro che ho contiene solo vagamente questi algoritmi,
Su internet ho cercato ma non ho capito.

[banryu79]

"Normalmente" non è neccessario creare un thread per processare fuori dall'EDT le azioni (actionPerformed) di un Button.
Anzi, proprio perchè tante volte la conseguenza di queste azioni, oltre all'esecuzione di una certa logica, è quella di apportare modifiche allo stato di componenti grafici e/o invocare operazioni quali repaint() sui componenti grafici, è neccessario che le operazioni stesse siano eseguite dall'EDT.

Il fatto che l'architettura di Swing e AWT è a thread singolo implica come conseguenza che tutte le operazioni grafiche sui componenti visualizzabili* devono essere eseguite dal thread apposito, l'EDT.

Quindi normalmente, come hai descritto tu, si lancia una finestra Swing, supponiamo un JFrame, dall'entry point dell'applicazione accodando le operazioni sulla Event Queue (la coda degli eventi grafici processata dall'EDT).
I metodi dei listener quali actionPerform() vengono ovviamente eseguiti dall'EDT perchè accodano sulla Event Queue le operazioni da svolgere.

A volte capita di dover associare alla pressione di un Bottone una qualche operazione che richiede un "lungo tempo" per essere eseguita: lasciarla processare dall'EDT significa tenerlo impegnato per quel tempo e quindi, detta in breve, bloccare la grafica finchè non ha finito.

Solo in questi casi si rende quindi neccessario creare e avviare un nuovo Thread che si occupi di "fare i calcoli" per lasciare libero l'EDT. Naturalmente, se alla "fine dei calcoli" si deve aggiornare qualche componente grafico, è neccessario sincronizzare in qualche modo il termine dell'esecuzione di questo nuovo Thread esterno con qualche operazione che apporti le modifiche grafiche richieste accodandole nella Event Queue (con invokeLater, ad esempio).

Oppure, se le cose si fanno complicate, ci si appoggia alla classe SwingWorker.

Se sei "novello" di Swing e dintorni, una lettura che ti consiglio davvero caldamente, tanto è adatta a chi si cimenta in Swing per la prima volta, è questo ottimo tutorial di un utente del forum:
- Swing espresso
Nelle primissime pagine ci sono le considerazioni sull'architettura a thread singolo di Swing/AWT; invece l'ultimo argomento parla propio dell'utilizzo di SwingWorker. Il tutorial è un pdf di 50 pagine, con i segnalibri dei capitoli, per un totale di 3 orette di lettura. Va bene poi conservarlo come una sorta di riferimento introduttivo ultrarapido quando si ha a che fare con nuovi componenti mai usai prima.

Per tutto il resto ci sono i Java Tutorial (cerca con Google "The really big index") e, ovviamente, i javadoc specifici della libreria.

[PGI-Bis]

E' una bella domanda perchè le possibilità che hai sono infinite. Al livello più basso c'è SwingWorker. Ti serve nel caso in cui tu voglia coordinare il lavoro di un Thread con l'EDT.

Ad esempio pigio il pulsante, parte il calcolone parallelo, al termine di quest'ultimo voglio aprire una finestra che dice "babau".

Qui i thread sono due: l'edt che cattura l'evento "pulsante premuto", il Thread che fa di conto e di nuovo l'EDT a cui deve essere delegato il "babau".

Il protocollo di SwingWorker ha un tot di ammennicoli ma i metodi di base sono tre: doInBackground, publish e process. L'uso è tipo Thread: crei una sottoclasse e start (solo che lo start si chiama execute). Esempio:

public void actionPerformed(ActionEvent e) {
    computeInBackground();
}

private void computeInBackground() {
    new SwingWorker<Void, Integer>() {

        public Void doInBackground() {
            int value = 0;
            for(int i = 0; i < value; i++) {
                value += 1;
            }
            publish(value);
            return null;
        }

        public void process(java.util.List<Integer> risultati) {
            Integer risultato = risultati.get(0);
            JOptionPane.showMessageDialog(un frame, "Risultato: " + risultato);
        }
    }.execute();
}

In breve "publish" invia a "process" e l'invio avviene in modo tale da garantire che quello che publish invia process riceva - cioè c'è una sincronizzazione del valore trasmesso che garantisce la visibilità all'EDT delle mutazioni di stato imposte dal Thread in background.

Poi c'è tutto l'armamentario delle API "concurrent" (java.util.concurrent e correlati). Qui se astrai il concetto di algoritmo in una funzione tipo:

public interface Function<A,R> {
    R eval(A...args);
}

puoi creare una coda in entrata di funzioni (LinkedBlockingQueue) da passare ad un pool di Thread di dimensioni fissa o variabile e comunicare i risultati all'EDT in blocco o progressivamente con una coda in uscita di altre funzioni.

Insomma, ce di che divertirsi.

[banryu79]

Bhe, l'alternativa più semplice di tutte, che a volte può bastare, non scomoda neanche una classe del framework. Presuuppone la possibilità di passare riferimenti ai componenti grafici da aggiornare in risposta al "calcone", se ce ne sono (non è detto serva sempre)

// inizializzato in questo scope:
final double initValue = someObject.getValue();

public void actionPerformed(ActionEvent e)  
{
    calcolone(); // implica una risposta grafica al termine della computazione
}

private void calcolone()
{
    Runnable computazione = new Runnable() {
        @Override
        public void run() {
            double mutable = initValue;
            ... calcolo lungherrimo qui...
            ... modifica valore di mutable...
            final double finalValue = mutable

            // qui ha finito: accoda evento grafico
            SwingUtilities.invokeLater(new Runnable()
            {
                @Override
                public void run() {
                    String message =String.valueOf(finalValue);
                    JOptionPane.showMessageOption(vattelapesca..., message, bla...);
                }
            });
        }
    };
    (new Thread(computazione)).start();
}

Oppure, se devo variare qualcosa in un componente esistente:

// inizializza in questo scope:
final double initValue = someObject.getValue();

public void actionPerformed(ActionEvent e)  
{
    calcolone(refComponente); // implica una risposta grafica al termine della computazione
}

private void calcolone(final JComponent refComponente) 
{
    Runnable computazione = new Runnable() {
        @Override
        public void run() {
            double mutable = initValue;
            ... calcolo lungherrimo qui...
            ... muta datoInteressante...
            final double finalValue = mutable;

            // qui ha finito: accoda evento grafico
            SwingUtilities.invokeLater(new Runnable()
            {
                @Override
                public void run() {
                    refComponente.setDatoInteressante(finalValue);
                    refComponente.repaint();
                }
            });
        }
    };
    (new Thread(computazione)).start();
}

@EDIT:

Originariamente inviato da PGI-bis

...
puoi creare una coda in entrata di funzioni (LinkedBlockingQueue) da passare ad un pool di Thread di dimensioni fissa o variabile e comunicare i risultati all'EDT in blocco o progressivamente con una coda in uscita di altre funzioni.

Interessante, quest'opzione non l'avevo ancora considerata.
Le conoscenze vanno messe assieme da soli dopo dovuto studio delle diverse "branche di conoscenza" (package java.util.concurrent, architettura di Swing, Generics...) oppure c'è qualche risorsa "furba" online a cui attingere (blog entry di qualche cervello della Sun, forum specifico...)?


@RIEDIT:
Modificato a seguito degli errori segnalati da PGI.

[PGI-Bis]

Non so cosa ci sia on-line ma ci sono una marea di libri sulla concorrenza in Java. Si può sempre partire da "Concurrent Programming in Java" di Doug Lea e andare avanti a oltranza.

P.s.: sul codice che hai incollato ci sarebbero un paio di cosine da sistemare ma diciamo che a grandi linee l'idea non è sbagliata.

[banryu79]

Originariamente inviato da PGI-Bis

P.s.: sul codice che hai incollato ci sarebbero un paio di cosine da sistemare ma diciamo che a grandi linee l'idea non è sbagliata.

Dica, duca!

[PGI-Bis]

Diciamo che al posto di questo

computazione.start();

c'è:

new Thread(computazione).start();

ma qui è un refuso.

Il problema è datoInteressante. Classico serpente che si morde la coda. Se è final, come è, allora è anche Thread-safe (l'EDT legge di certo ciò che ci sta scritto sopra). Ma non è mutabile.

Se non fosse final sarebbe mutabile ma non più Thread-Safe: l'edt potrebbe benissimo leggere zero. E comunque il compilatore direbbe "ciccia" perchè una variabile in tanto può essere passata ad una classe locale in quanto abbia un valore definitivamente assegnato.

Dunque per mantenere l'equilibrio quel "datoInteressante" deve essere:

1. final perchè viene usato in una classe locale
2. mutabile perchè il Thread "locale" vuole cambiarlo
3. Thread-Safe perchè un secondo Thread - l'EDT - vuole leggere il risultato.

Questione che SwingWorker affronta internamente e in modo trasparente nel passaggio publish-process.

[banryu79]

Diciamo che al posto di questo

computazione.start();

c'è:

new Thread(computazione).start();

ma qui è un refuso.

Ops, eh-eh, mi è scappato. Corretto sopra.

Se non fosse final sarebbe mutabile ma non più Thread-Safe: l'edt potrebbe benissimo leggere zero. E comunque il compilatore direbbe "ciccia" perchè una variabile in tanto può essere passata ad una classe locale in quanto abbia un valore definitivamente assegnato.

Ah, già, è quella faccenda dell'"happens before"... Non ho ancora sviluppato un colpo d'occhio per queste cose.

Per il discorso del dato mutabile e final, chiaramente ho cannato a usare un tipo primitivo: lo dichiaro final e il suo tipo lo dichiaro Double.
Per l'"happens before" semplicemente non lo dichiaro locale al metodo "calcolone" ma lo dichiaro e inizializzo nello scope subito più alto (sempre final).

Ehm, soluzione spartana in effetti, potrebbe essere apprezzabile per casi una tantum piuttosto semplici.
Stavo pensando a come realizzare una piccola astrazione per riutilizzare il meccanismo, ma credo che così facendo ci si spinga in una direzione che tende a puntare a questo:

Questione che SwingWorker affronta internamente e in modo trasparente nel passaggio publish-process.

Potrebbe avere una valenza didattica, però.

[PGI-Bis]

Double o double cambia poco. Double è immutabile, se lo dichiari final il suo valore si cementa. Serve comunque una struttura più complessa (sul genere degli AtomicXYZ) oppure fai una cosa di questo tipo:

final double valoreIniziale = qualcosa;
new Thread() {
    public void run() {
        double x = valoreIniziale

        x = x + un conto che lèvati

        final double y = x;
        EventQueue.invokeLater(new Runnable() {
            public void run() {
                ta-dah => y.
            }
        });
    }
}.start();

Qui sfrutti la "semantica" del final che dice che il valore di una variabile final è sempre visibile a prescindere da quale thread vi acceda: il codice è thread safe senza un solo "lock".

In effetti per la comunicazione di valori tra Thread "final" è il grande messaggero. Non solo per i primitivi ma anche per i riferimenti qualora gli oggetti riferiti possiedano solo campi final.

[banryu79]

Originariamente inviato da PGI-Bis

Double o double cambia poco. Double è immutabile, se lo dichiari final il suo valore si cementa.

Ari-ops, eh-eh, so' proprio na sola... Nella mia testa mentre rispondevo pensavo ad un metodo setValue che in effetti, i wrapper dei tipi primitivi non hanno

Originariamente inviato da PGI-Bis

final double valoreIniziale = qualcosa;
new Thread() {
    public void run() {
        double x = valoreIniziale

        x = x + un conto che lèvati

        final double y = x;
        EventQueue.invokeLater(new Runnable() {
            public void run() {
                ta-dah => y.
            }
        });
    }
}.start();

Ecco, questo mi piace molto, da un punto di vista "educativo", diciamo.
Lo trovo semplice e chiaro.

[DNAx86]

Interessante SwingWorker
e ottima la guida rapida di SWING,

ma ci ho pensato affondo e purtoppo non penso facciano al caso mio

Di base ho 2 pulsanti.
Ogniuno fà avviare un lungo calcolo e solo uno dei due pulsanti ha esito grafico (ma non è questo il mio problema, per ora).

Il mio problema è che il secondo pulsante genera dati in un nuovo thread usando come input i dati generati dal thread del primo pulsante.

Sebbene il problema sembri quello del produttore consumatore, così non è,
perchè non voglio che il 2° thread che utilizza i dati generati dal 1° thread in un ciclo ben definito (nei classici esempi c'è un for che alterna il lavoro produttore-consumatore),
ma voglio che chi detta le regole siano i 2 pulsanti un pulsante genera,
l'altro usa i dati per fare altri calcoli lunghi e poi disegnare il risultato.
Inoltre i 2 thread hanno un paramentro in input che determina come devono fare il lavoro, quindi non posso semplicemente creare i due thread e poi avviarli, ma prima di riavviarli (o in qualche modo, durante) devo passarli questo parametro: come?

Non sò come fare, non mi sembra appropirato wait() e notify(),
SwingWorker non credo faccia al caso,

Bohhhhhhhhh


Spero mi sappiate dare un'altro consiglio,
non sò che fare, sono totalmente inpallato.

[PGI-Bis]

Mi sono perso per strada. Riassumo, correggimi dove i conti non tornano.

Hai un thread A che esegue un certo calcolo. Prima di poter essere avviato questo Thread deve ricevere un parametro di configurazione. Questo parametro può cambiare durante l'esecuzione del Thread. Il Thread A produce dei valori.

Hai un thread B che esegue un certo altro calcolo. Prima di poter essere avviato deve ricevere un parametro di configurazione che può cambiare durante l'esecuzione del Thread. Il calcolo di B dipende dall'esistenza di uno o più valori prodotti dal Thread A.

L'esecuzione del Thread A è avviata da un pulsante PA e l'esecuzione del Thread B è avviata da un pulsante PB.

Chiedo una conferma perchè una volta che il modello è ben definito la sua realizzazione è sempre una sciocchezzuola.

[DNAx86]

Originariamente inviato da PGI-Bis

Mi sono perso per strada. Riassumo, correggimi dove i conti non tornano.

Hai un thread A che esegue un certo calcolo. Prima di poter essere avviato questo Thread deve ricevere un parametro di configurazione. Questo parametro può cambiare durante l'esecuzione del Thread. Il Thread A produce dei valori.

Hai un thread B che esegue un certo altro calcolo. Prima di poter essere avviato deve ricevere un parametro di configurazione che può cambiare durante l'esecuzione del Thread. Il calcolo di B dipende dall'esistenza di uno o più valori prodotti dal Thread A.

L'esecuzione del Thread A è avviata da un pulsante PA e l'esecuzione del Thread B è avviata da un pulsante PB.

Chiedo una conferma perchè una volta che il modello è ben definito la sua realizzazione è sempre una sciocchezzuola.

Innanzitutto, grazie della tua disponibilità.
Tornando al programma, che in effetti non avevo spiegato al meglio:

Hai un thread A che esegue un certo calcolo.
Prima di poter essere avviato questo Thread deve ricevere un parametro di configurazione.
Questo parametro può cambiare durante l'esecuzione del Thread,
ma se varia non è necessario comunicarlo subito al Thread:
lo si utilizzerà la prossima volta che il Thread sarà avviato.
Il Thread A produce dei valori.

Hai un thread B che esegue un certo altro calcolo.
Prima di poter essere avviato deve ricevere un parametro di configurazione che può cambiare durante l'esecuzione del Thread,
ma se varia non è necessario comunicarlo subito al Thread:
lo si utilizzerà la prossima volta che il Thread sarà avviato.
Il calcolo di B dipende dall'esistenza di uno o più valori prodotti dal Thread A.
Alla fine del calcolo di B, si deve comunire ai componenti swing il risultato.

L'esecuzione del Thread A è avviata da un pulsante PA e l'esecuzione del Thread B è avviata da un pulsante PB.

[PGI-Bis]

Perfetto. Abbiamo già uno schema possibile.

BeanConfigurazione, un bean concorrente che trattiene i parametri di configurazione
CodaRisultatiA, una coda in cui Thread A riversa il prodotto del suo calcolo, condivisa tra Thread A e ThreadB

Premo il pulsante PA, Thread A parte, ottiene da BeanConfigurazione i parametri di configurazione. Se i parametri di configurazione esistono, inizia il calcolo e immette il risultato o i risultati nella CodaRisultatiA.

Premo il pulsante PB, Thread B parte, ottiene da BeanConfigurazione i parametri di configurazione. Se i parametri di configurazione esistono, prende i risultati di ThreadA dalla CodaRisultatiA. Se questi risultati esitono, inizia il calcolo al termine del quale notifica all'EDT quel che deve. Thread B potrebbe essere gestito da uno SwingWorker - per via del piede in due staffe, EDT-non EDT.

Devi solo determinare cosa succede nel caso in cui i SE non si verifichino.

Se non c'è una configurazione in BeanConfigurazione cosa fanno i Thread? Terminano immediatamente l'esecuzione senza produrre/analizzare risultati o si mettono in attesa che qualcuno crei la configurazione?

Se Thread B non trova risultati nella CodaRisultatiA, termina immediatamente o si mette in attesa che questi risultati siano prodotti?

[DNAx86]

Originariamente inviato da PGI-Bis

Perfetto. Abbiamo già uno schema possibile.

BeanConfigurazione, un bean concorrente che trattiene i parametri di configurazione
CodaRisultatiA, una coda in cui Thread A riversa il prodotto del suo calcolo, condivisa tra Thread A e ThreadB

Premo il pulsante PA, Thread A parte, ottiene da BeanConfigurazione i parametri di configurazione. Se i parametri di configurazione esistono, inizia il calcolo e immette il risultato o i risultati nella CodaRisultatiA.

Premo il pulsante PB, Thread B parte, ottiene da BeanConfigurazione i parametri di configurazione. Se i parametri di configurazione esistono, prende i risultati di ThreadA dalla CodaRisultatiA. Se questi risultati esitono, inizia il calcolo al termine del quale notifica all'EDT quel che deve. Thread B potrebbe essere gestito da uno SwingWorker - per via del piede in due staffe, EDT-non EDT.

Devi solo determinare cosa succede nel caso in cui i SE non si verifichino.

Se non c'è una configurazione in BeanConfigurazione cosa fanno i Thread? Terminano immediatamente l'esecuzione senza produrre/analizzare risultati o si mettono in attesa che qualcuno crei la configurazione?

Se Thread B non trova risultati nella CodaRisultatiA, termina immediatamente o si mette in attesa che questi risultati siano prodotti?

Non ho mai usato Java Bean, ho visto che c'è ne sono di tanti tipi, nel frattempo che li studio, Potresti dirmi come si chiama il Bean che dovrei usare nel mio contesto?

Per implementare la coda che classe mi consigli?

Grazie

[PGI-Bis]

In senso generale bean è qualsiasi classe Java che definisca un metodo di accesso per ogni campo privato secondo lo schema getNomeCampo, setNomeCampo - cosa che rende la classe candidabile all'uso come JavaBean in senso proprio. Il tuo bean avrà la forma:

public class Configurazione {
    private String valoreIpotetico;

    public synchronized String getValoreIpotetico() {
        return valoreIpotetico;
    }

    public synchronized void setValoreIpotetico(String v) {
        valoreIpotetico = v;
    }
}

I campi effettivi dipendono dai parametri di configurazione di cui i tuoi Thread hanno bisogno.

Per la coda c'è già pronta java.util.concurrent.LinkedBlockingQueue.

[DNAx86]

Grazie, ora provo ad implementare il tutto

[DNAx86]

Per comunicare i risultati da un nuovo Thread alla GUI,
creo il thred newRunnableObject e poi:
EventQueue.invokeLater( newRunnableObject ) ?

[PGI-Bis]

Usa SwingWorker. Altrimenti devi gestire la coerenza degli assegnamenti. Vale a dire che non basta passare il valore da un Thread all'EDT tramite EventQueue per poter essere certi del risultato. Occorre che il passaggio sia "thread-safe".

[DNAx86]

Sto finendo l'implementazione,

DOMANI VI FACCIO SAPERE,

Stay tuned