faretesto > comp.lang.* > comp.java

dashk (24.11.2006, 15:46)
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++;
}
}
Gian Uberto Lauri (24.11.2006, 16:28)
>>>>> Long count = 12.19.13.15.1; tzolkin = 8 Imix; haab = 14 Ceh.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "d" == dashk <nomail> 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.
dashk (24.11.2006, 17:16)
Gian Uberto Lauri ha scritto:

> >>>>> Long count = 12.19.13.15.1; tzolkin = 8 Imix; haab = 14 Ceh.
> >>>>> I get words from the Allmighty Great Gnus that
> >>>>> "d" == dashk <nomail> writes:


> Per me il problema e` che continui a creare thread.


problema di memoria? ma il garbage collector non rimuove il riferimento a
un thread quando questo termina?

o intendi un problema di ottimizzazione? nel senso meglio istanziare 20
thread subito, in quanto l'operazione di istanziamento in se è uno spreco
di tempo?

> A naso è quello che fa il ThreadPoolExecutor della Java 1.5.


siamo fermi alla 1.4 e per chissà quanto tempo ancora...
Gian Uberto Lauri (24.11.2006, 18:34)
>>>>> Long count = 12.19.13.15.1; tzolkin = 8 Imix; haab = 14 Ceh.
>>>>> I get words from the Allmighty Great Gnus that
>>>>> "d" == dashk <nomail> writes:


> 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.
Discussioni simili