Newsgroup: it.comp.java
Titolo: aiuto thread (2)

Ciao a tutti! con i consigli dell'altro thread e leggendo la
documentazione penso di aver risolto il problema, il codice sembra
funzionare ed è molto più veloce della versione sequenziale... quello che
volevo chiedervi è se secondo voi è corretto e se si può migliorare
l'efficenza di quel ciclo while.
Il problema era:
Ho un arraylist di bean e per ogni bean devo avviare una determinata
sequenza di operazioni(accesso a db tramite valori trovati nel bean,
calcoli vari, scrittura risultato su un altro db)... invece di fare tutto
sequenzialmente, cioè bean per bean, ho pensato di usare i thread per
velocizzare la cosa, in particolare vorrei che in esecuzione ci fosse
sempre un numero finito di thread, ad esempio 20
ArrayList beans = ....
ThreadGroup threadPool = new ThreadGroup("pool");
Thread tempThread = null; 
Iterator beanIterator = beans.iterator();
int counter = 0;
while(counter < beans.size()) {
    if(threadPool.activeCount() < 20 && beanIterator.hasNext() == true) {
        tempThread = new Thread(threadPool, new
ThreadLsPtUc(beanIterator.next()); //ThreadLsPtUc implementa Runnable e
che rappresenta la sequenza di operazioni che deve essere eseguita per
ogni bean
        tempThread.start();
        counter++;
    }
}
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 writes:
d> Il problema era: Ho un arraylist di bean e per ogni bean devo
d> avviare una determinata sequenza di operazioni(accesso a db tramite
d> valori trovati nel bean, calcoli vari, scrittura risultato su un
d> altro db)... invece di fare tutto sequenzialmente, cioč bean per
d> bean, ho pensato di usare i thread per velocizzare la cosa, in
d> particolare vorrei che in esecuzione ci fosse sempre un numero
d> finito di thread, ad esempio 20
Per me il problema e` che continui a creare thread.
Dovresti creare  una volta  per tutte i  20 thread  e poi fare  si che
ciascun thread vada  a prendersi il lavoro da  fare da un distributore
di  beans  (questa  č  una  tecnica ispirata  al  funzionamento  della
libreria Cilk del MIT).
Per evitare colli di bottiglia di accodamenti al distributore (i tempi
di servizio a naso non differiscono molto) puoi pensare di suddividere
i bean tra piů distributori  ciascuno dedicato ad un insieme di thread
Ma questo ha senso se riesci  a farlo "a basso costo".  Ad esempio con
5 distributori questi potrebbero distribuire, per n>=0:
             d1 bean Nr. 5*n
             d2 bean Nr. (5*n)+1
             d3 bean Nr. (5*n)+2
             d4 bean Nr. (5*n)+3
             d5 bean Nr. (5*n)+4
A naso č quello che fa il ThreadPoolExecutor della Java 1.5.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 A naso è quello che fa il ThreadPoolExecutor della Java 1.5.
siamo fermi alla 1.4 e per chissà quanto tempo ancora...


 Per me il problema e` che continui a creare thread.
d> problema di memoria? ma il garbage collector non rimuove il riferimento a
d> un thread quando questo termina?
Il garbage collector parte quando gli "pare e piace".
d> o intendi un problema di ottimizzazione? nel senso meglio istanziare 20
d> thread subito, in quanto l'operazione di istanziamento in se č uno spreco
d> di tempo?
La  seconda  principalmente.  Che   oltretutto  se  il  gc  non  parte
l'allocazione diviene piů lenta.
