Anonimamente22 ha scritto:
Concettualmente fatto cosi' è giusto l'esercizio?
No, non è affatto corretto.
Partiamo dalla tua classe random. Non ha granché senso di esistere, per come l'hai fatta non dà alcun "valore aggiunto". Se facesse qualcosa di più es. tirar fuori un valore casuale compreso tra
n e
m, allora potrebbe avere più senso. In ogni caso, una cosa: ti basta 1 solo oggetto java.util.Random, non uno per ciascun thread.
C'è poi un'altra cosa che comunque ti è sfuggita (o non l'hai letta): il nextDouble() restituisce un valore compreso tra 0.0 (incluso) e 1.0 (
escluso!). Quindi non è MAI esattamente 1. Tu poi fai un cast a long per passarlo a sleep. Siccome il valore è sempre 0.xxxx, il cast tronca i decimali e hai SEMPRE 0. Quindi usato così, non serve a nulla.
Al Thread.sleep(n) devi passare un valore in
millisecondi. Quindi 1000 per fare 1 secondo. Puoi decidere tu un intervallo di valori interi, es. tra 500 (mezzo secondo) a 2000 (due secondi). Ma devi usare opportunamente il java.util.Random per ottenere tu questo intervallo.
Poi comunque ci sono errori di concetto sui thread.
Fai un ciclo for per fare tutti gli start:
for(int i=0;i<10;i++)
{
prova[i].start();
}
Attenzione che start() NON fa partire subito il run() di un thread. Mette solo il thread in stato "runnable" (cioè che PUO' essere schedulato) ma poi dipende appunto dallo scheduler dei thread decidere QUANDO avviare il thread. E questo purtroppo è molto aleatorio (dipende pure dal S.O.).
Detto in altro modo: la parte successiva che è molto veloce (fino a prima dell'ultimo println) potrebbe
in teoria (e con tempistiche sfortunate) addirittura essere eseguita PRIMA che tutti i tuoi thread inizino la esecuzione. Quindi scritto così NON ha senso.
L'avevo detto prima. Se vuoi determinare il primo che "arriva" alla fine, devi avere un metodo che faccia da "barriera", che tutti i thread devono invocare esplicitamente alla loro fine.
Pensa a quanto appena detto e riscrivi il tutto.