View Full Version : [Java] - Swing e Threads
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.
:mc: :mc: :mc: :mc:
banryu79
31-08-2009, 13:47
"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 (http://www.hwupgrade.it/forum/showthread.php?t=2005654)
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.
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
31-08-2009, 14:35
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:
...
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.
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
31-08-2009, 15:19
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! :D
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
31-08-2009, 16:25
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ò.
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
31-08-2009, 17:07
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 :p
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.
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 :mc: :mc: :mc:
Spero mi sappiate dare un'altro consiglio,
non sò che fare, sono totalmente inpallato.
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.
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.
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?
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
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.
Grazie, ora provo ad implementare il tutto
Per comunicare i risultati da un nuovo Thread alla GUI,
creo il thred newRunnableObject e poi:
EventQueue.invokeLater( newRunnableObject ) ?
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".
Sto finendo l'implementazione,
DOMANI VI FACCIO SAPERE,
Stay tuned
Stò analizzando i test del Profiler,
Ho notato che (anche se il programma funziona correttamente, per ora)
i thread creati con swingworker quando finiscono le istruzioni non muoiono, ma rimangono zombie.
E' "normale?
Si può evitare di lasciare questi zombie attivi?
E' un comportamento normale che ha lo scopo di migliorare le performance. In generale l'operazione "new Thread()" è relativamente dispendiosa. Ogni SwingWorker accede ad un pool di Thread comune e se esiste usa un Thread libero già in vita per eseguire le sue operazioni.
Il profiler dovrebbe dirti che quei Thread sono in stato "waiting" o qualcosa del genere. Un Thread addormentato non consuma cicli CPU ma solo qualche byte in memoria quindi gli svantaggi sono veramente minimi per non dire quasi assenti.
Se vuoi evitarlo devi creare un'alternativa a SwingWorker.
E' un comportamento normale che ha lo scopo di migliorare le performance. In generale l'operazione "new Thread()" è relativamente dispendiosa. Ogni SwingWorker accede ad un pool di Thread comune e se esiste usa un Thread libero già in vita per eseguire le sue operazioni.
Il profiler dovrebbe dirti che quei Thread sono in stato "waiting" o qualcosa del genere. Un Thread addormentato non consuma cicli CPU ma solo qualche byte in memoria quindi gli svantaggi sono veramente minimi per non dire quasi assenti.
Se vuoi evitarlo devi creare un'alternativa a SwingWorker.
Ieri mi ero dimenticato di dire che però anche gli altri 2 thread creati usando Runnable continuano ad esistere,anche se non eseguono più calcoli.
Credo che questo sia dovuto al fatto che nessun thread li "aspetta" con wait.
Il punto è che nel mio contesto non c'è il sistema wait - notify.
Il pulsanteA, crea OggettoA che implementa Runnable (così imposto i parametri che cambiano) e lo imposta, quindi crea ThreadA genera e mette in stackA,
Il pulsanteB, crea Oggetto che implementa Runnable (così imposto i parametri che cambiano) e lo imposta, quindi crea ThreadB ,usa la testa di StackA, genera e mette in StackB
Il pulsanteC crea SwingWorker-Thread (usa lo stackB), lo usa per impostare la grafica con il risultato.
In questo contesto (pulsanteC aggiunto per semplificare le cose) non mi è servito usare wait-notifi,
ma come faccio a fare morire i threadA e B ?
PS: non mi è servito nemmeno usare una classe con i metodi serialized, perchè dell'output se ne occupa lo SwingWorker-Thread che prende uno ed un solo elemento dalla testa dello stack e disegna il risultato (questo quando si preme il pulsanteC).
Se il pulsanteC fosse premuto più volte, questo non dovrebbe richiamare altri SwingWorker-Thread, per definizione di SwingWorker e quindi non c'è accesso concorrente alla risorsa che si usa per l'output, corregetemi se sbaglio
un Thread muore quando termina il suo compito.
new Thread("il mio thread") {
public void run() {
System.out.println("piripacchio");
}
}.start();
Questo stampa "piripacchio" e schiatta. Quando termina il metodo run del Thread ( o del suo Runnable) il Thread è a tutti gli effetti deceduto.
Se i tuoi Thread non muoiono verifica il loro stato con il profiler. Se sono in "wait" allora c'è qualcosa che non va nel tuo codice. Nomina sempre i Thread che crei, per poterli identificare nei profiler.
La sincronizzazione serve. Dipende poi se serva anche farsela a mano o no. Ad esempio LinkedBlockingQueue stabilisce una relazione happes-before tra le operazioni che un Thread compie prima di mettere un dato nella coda e l'estrazione del dato dalla coda da parte di un altro Thread. Significa che se un Thread A dice "x = 10" e poi mette x nella coda quando il Thread B estrae x dalla coda vede necessariamente il suo valore a 10.
Se stackA e stackB sono pile che stabiliscono una relazione simile tra push e pop allora non è necessario che esista una sincronizzazione "manuale" a patto che il dato sia creato dal Thread che poi lo immetterà nella pila.
Se il metodo actionPerformed associato al pulsante C crea uno SwingWorker allora ogni volta che premi C parte necessariamente un nuovo SwingWorker: non ci sono santi che tengano. Lo SwingWorker poi potrà o meno creare un novo Thread per eseguire le operazioni in background (dipende dallo stato del pool a cui si appoggia: se tutti i thread sono occupati e non è ancora stato raggiunto il limite di saturazione allora salterà fuori un nuovo Thread altrimenti uno degli esistenti sarà riciclato).
Per quanto riguarda SwingWorker non è necessario sincronizzare esplicitamente letture e scritture di dati CREATI nel metodo doInBackground e letti nel metodo process perchè tra publish e process esiste una relazione happens-before (propriamente la relazione che sussiste è tra le scritture operate su dati creati nel metodo doInBackground e notificate tramite publish e le letture degli stessi dati nel metodo process).
Bisogna vedere se questa sincronizzazione sia necessaria nel caso specifico nel senso che quando ho parlato di questo "bean sincronizzato" l'ho fatto in relazione all'ipotesi che i parametri di configurazione fossero genericamente creati da un Thread diverso da quello che li avrebbe letti. Dopodichè è sicuramente possibile avvalersi o dei meccanismi di sincronizzazione impliciti in SwingWorker o nelle API concurrent oppure non sincronizzare affatto sfruttando la semantica del modello di memoria del linguaggio Java. Vedi il modificatore final, il modificatore volatile, l'avvio di un nuovo Thread eccetera.
In ogni caso il principio in questione è semplice: se stai creando o modificando un valore in un Thread e questo valore dovrà essere letto da un Thread diverso devi drizzare le orecchie: se non trovi conferma nelle API che usi o nel JMM dell'esistenza di relazioni happens-before sincronizza le letture e le scritture.
un Thread muore quando termina il suo compito.
new Thread("il mio thread") {
public void run() {
System.out.println("piripacchio");
}
}.start();
Questo stampa "piripacchio" e schiatta. Quando termina il metodo run del Thread ( o del suo Runnable) il Thread è a tutti gli effetti deceduto.
Se i tuoi Thread non muoiono verifica il loro stato con il profiler. Se sono in "wait" allora c'è qualcosa che non va nel tuo codice. Nomina sempre i Thread che crei, per poterli identificare nei profiler.
La sincronizzazione serve. Dipende poi se serva anche farsela a mano o no. Ad esempio LinkedBlockingQueue stabilisce una relazione happes-before tra le operazioni che un Thread compie prima di mettere un dato nella coda e l'estrazione del dato dalla coda da parte di un altro Thread. Significa che se un Thread A dice "x = 10" e poi mette x nella coda quando il Thread B estrae x dalla coda vede necessariamente il suo valore a 10.
Se stackA e stackB sono pile che stabiliscono una relazione simile tra push e pop allora non è necessario che esista una sincronizzazione "manuale" a patto che il dato sia creato dal Thread che poi lo immetterà nella pila.
Se il metodo actionPerformed associato al pulsante C crea uno SwingWorker allora ogni volta che premi C parte necessariamente un nuovo SwingWorker: non ci sono santi che tengano. Lo SwingWorker poi potrà o meno creare un novo Thread per eseguire le operazioni in background (dipende dallo stato del pool a cui si appoggia: se tutti i thread sono occupati e non è ancora stato raggiunto il limite di saturazione allora salterà fuori un nuovo Thread altrimenti uno degli esistenti sarà riciclato).
Per quanto riguarda SwingWorker non è necessario sincronizzare esplicitamente letture e scritture di dati CREATI nel metodo doInBackground e letti nel metodo process perchè tra publish e process esiste una relazione happens-before (propriamente la relazione che sussiste è tra le scritture operate su dati creati nel metodo doInBackground e notificate tramite publish e le letture degli stessi dati nel metodo process).
Bisogna vedere se questa sincronizzazione sia necessaria nel caso specifico nel senso che quando ho parlato di questo "bean sincronizzato" l'ho fatto in relazione all'ipotesi che i parametri di configurazione fossero genericamente creati da un Thread diverso da quello che li avrebbe letti. Dopodichè è sicuramente possibile avvalersi o dei meccanismi di sincronizzazione impliciti in SwingWorker o nelle API concurrent oppure non sincronizzare affatto sfruttando la semantica del modello di memoria del linguaggio Java. Vedi il modificatore final, il modificatore volatile, l'avvio di un nuovo Thread eccetera.
In ogni caso il principio in questione è semplice: se stai creando o modificando un valore in un Thread e questo valore dovrà essere letto da un Thread diverso devi drizzare le orecchie: se non trovi conferma nelle API che usi o nel JMM dell'esistenza di relazioni happens-before sincronizza le letture e le scritture.
Il profiler di netbeans ha 4 stati nella leggenda:
Running (verde),
Sleeping (Viola),
Wait (Giallo),
Monitor (Rosa).
I thread che io considero vivi sono invece:
Bianchi,
Dello stesso colore del main e dello stesso colore degli swingworker-threads.
Quindi che stato sono?
E' sbagliato che rimangano lì?
Lo eviterei con wait-notifi ?
Che comunque non saprei come metterli dato che i thread lavorano sulle code e non lavorano in blocchi syncrhonized
Quelli che non sono nè verdi, nè viola, nè gialli nè rosa sono morti :).
Se vai nella scheda "dettagli" vedi che riporta "finished".
wait e notify sono due semplici meccanismi per la gestione di un'interruzione condizionata del ciclo vitale di un Thread, integrati nel linguaggio, a cui tutte le API Java per la programmazione concorrente già si appoggiano.
Non è che "usando wait e notify" si faccia programmazione concorrente Java in un modo diverso da quella che si fa usando SwingWorker o LinkedBlockingQueue o altro: sempre di wait e notify si tratta solo che nel secondo caso lasci che sia lo strumento di livello più elevato a gestirli. Per dire: li stai già usando, per via indiretta.
banryu79
02-09-2009, 13:20
Altro thread del forum da "bookmarkare" comunque, grazie PGI :)
Quelli che non sono nè verdi, nè viola, nè gialli nè rosa sono morti :).
Se vai nella scheda "dettagli" vedi che riporta "finished".
wait e notify sono due semplici meccanismi per la gestione di un'interruzione condizionata del ciclo vitale di un Thread, integrati nel linguaggio, a cui tutte le API Java per la programmazione concorrente già si appoggiano.
Non è che "usando wait e notify" si faccia programmazione concorrente Java in un modo diverso da quella che si fa usando SwingWorker o LinkedBlockingQueue o altro: sempre di wait e notify si tratta solo che nel secondo caso lasci che sia lo strumento di livello più elevato a gestirli. Per dire: li stai già usando, per via indiretta.
Sono riuscito a mettere a frutto i tuoi consigli dati in questi giorni,
ti ringrazio,
con questa sistemata finale ho ultimato l'applicazione,
la mia prima seria applicazione java. :cool:
Ciao PGI
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.