Newsgroup: it.comp.java
Titolo: confusione sui thread

Ciao a tutti .
scusate la domanda per voi banale , ma leggendo sui thread ho capito che 
servono per far fare ai programmi delle altre cose per esempio mentre carica 
dei dati o altro.
Ma visto che solo  un thread per volta puo occupare il processore ,(ossia un 
thread viene messo a doirmire mentre l'altro prende il sopravvento)  mi 
chiedo : come fa quindi a svolgere piu compiti contmporaneamente?
ossia per un esempio pratico: poniamo che in un progreamma ad un certo punto 
debba caricare delle immagini.
Ovvio che per caricarne molte impiega un certo tempo.
Secondo quanto ho capito è possibile che mentre il programma carica queste 
immagini contmporaneamente faccia altro per esempio nelle videate di 
installazione dei programmi appaiono altre schermate..  alla fine poi torna 
al compito principale per visualizzare le immaginni che stava caricando 
prima.
Mi potete aiutare a capire il concetto ? grazie mille .
Mauro
. 

 Mauro
 
La CPU e' parecchi ordini di grandezza piu' veloce dell' Iinput-Output IO.
Cosi' la stragrande maggioranza del tempo ( anche 99% ) i Programmi lo
passano in IO
SI fa allora "scheduling" della CPU, cioe' la si da a turno ai vari
Programmi ( Thread ) tramite diverse politiche di assegnamento . Cosi questi
che mentre aspettano il proprio turno possono fare IO in parallelo.
Questo e' il ragionamento base, poi ci sono molte altre tecniche di
pipeline, di caching, di networking, di rete, di CPU multiple, di
distribuzione di logica, di balancing, e alto, che permettono ai 3d di
operare in modo concorrente.
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

chiedo : come fa quindi a svolgere piu compiti contmporaneamente?
I thread occupano il processore, uno alla volta, per brevi intervalli
di tempo. Il sistema operativo compie uno scheduling dei task,
assegnando brevi frame di tempo ad ogni task perché esegua i suoi
compiti. Quello che vedi č, difatti, uno pseudo-parallelismo; non ti
accorgi che lo sia perché gli intervalli di tempo assegnati dal
sistema ad ogni task sono dell'ordine di millisecondi.
Ovviamente esistono (ormai ci sono anche per i PC casalinghi),
architetture multiprocessore, in cui puņ esserci parallelismo vero e
quindi le cose si complicano.
Ti č chiaro?

 Ti è chiaro? 

proprio compito ? Oppure solo nel caso in cui il metodo è sincronizzato ?
Perdonami, ma se hai capito che il s.o. fa svolgere i compiti ai vari
thread alternativamente per brevi frazioni di tempo, non dovresti
avere ancora questo dubbio. Come già detto, il sistema operativo
schedula i task perché si alternino nell'uso del processore
garantendo, alla lunga, quello che è uno pseudo-parallelismo.
Cioè, non vi è parallelismo vero, ma solo una sequenza unica di
operazioni che durano talmente poco da sembrare parallele. Mettiamo,
per esempio, che il task A abbia le istuzioni a1,a2,a3,a4,a5 e il task
B le istruzioni b1,b2,b3. Semplificando al massimo, la sequenza di
istruzioni eseguite dall'unico processore potrebbe essere:
a1
b1
a2
b2
a3
b3
a4
a5
E' per queso che in un unico programma, tu hai più compiti eseguiti
contemporaneamente.

Oppure solo nel caso in cui il metodo è sincronizzato ?
Mi era sfuggita questa domanda. Ovviamente la sequenza che ho
descritto prima vale nel caso in cui due thread non siano
sincronizzati e l'uno non stia aspettando che l'altro rilasci
l'oggetto di sincronizzazione (mutex, evento, semaforo, critical
section, ecc...). La sincronizzazione è d'obbligo quando più thread
possono "pestarsi i piedi" a vicenda nell'accedere a risorse
condivise. Immagina che vi sia un contatore in un'applicazione e che
sia regola inderogabile quella che ogni thread debba poter calcolare
il prossimo numero, in sequenza, e in maniera univoca. Se non si
sincronizza l'accesso al contatore, è molto probabile che i thread
finiscano per prelevare gli stessi valori la stragrande maggioranza
delle volte, invalidando la regola. Sincronizzando l'accesso alla
risorsa, invece, ogni thread attende che l'altro abbia finito e quindi
la sequenza e univocità dei valori di ogni thread è garantita.

Ti ringrazio sei stato iper gentilissimo.!!!!!!!!!!!!!!!
Finalmente ho capito . Scusa ma studio java come autodidatta e quindi certi 
concetti non li afferro subito .
Ho letto sul mnualke di java scritto da claudio de sio che è preferibile 
sincronizzare un metodo piuttosto che sincronizzare un oggetto.
ossia : syncornized metod () {................... }
meglio di sincronized (object )
che mi dici ?
Inoltre sapresti darmi qualche link dove posso trovare degli esempi di 
applicazioni che utilizzano molti thread ?
Anche su esempi sul sito sun
Grazie ancora per la tua disponibilità .
Mauro
"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:58m6r3l2af9e2282c...@4ax.com...


applicazioni che utilizzano molti thread ?
Mi spiace, non conosco link del genere. In ogni caso, applicazioni che
utilizzano *molti* thread, non sono quasi mai buone applicazioni,
perché il multithreading è un ambiente in cui, anche per cose banali,
si amplificano le possibilità d'errore in maniera sorprendetemente
facile. Io ti consiglio di usare i thread solo se realmente
necessario. Spero di esserti stato d'aiuto ;-)

 che mi dici ?
Il suggerimento e' corretto perche' migliora la leggibilita'
dell'applicazione e diminuisce la possibilita' di errore. Occhio che quando
programmi concurrent la possibilta' di errore e' altissima perche' non e'
facile simulare una caso reale con milioni di accessi contemporanei per
parecchio tempo e quindi di solito la tua applicazione "funziona" a vista
provandola anche se ha dentro un bug che poi ti ammazza.
 Tieni pero' presente che e' una sfumatura usare una via o l'altra . DI fatto
se sincronizzi i metodi fai delle micro classi ( che si chiamano monitor )
con dei metodi sincronizzati che "bloccano" ( lockano) un singolo oggetto.
Se vuoi lockare 2 oggetti nella stessa classe monitor in quel caso usi
sincronized (object )
L'argomento e' piuttosto complesso per
la documentazione non so che consigliarti, forse googlare un po' in "zona
Sun" e' una via, ma meglio se ti leggi un testo di concorrenza generica (
vedi il classico
Sistemi Operativi di Silberschatz Abraham
, basta il capitolo della concorrenza )
e poi eventualmente passi a qualcosa di piu' specifico su "Java Concurrent"
che operativamente e' molto piu' facile che usare i semafori dei Sistemi
Operativi
Ultima cosa , se inizi qualche regola base da stamparsi sulla fronte :
-) non usare i metodi deprecati
-) Non fare mai polling di nessun tipo, cioe' non fare mai sleep- mi
sveglio, e controllo il mondo e decido che fare, usa invece wait-signal
-) Lascia sempre la wait come ultima riga del metodo
-) Ricordati che quando entri in un metodo synchronized chiudi fuori i cani
da TUTTI i metodi synchronized della stessa classe fino a quando esci dal
metodo o vai in wait
-) Non usare mai la sleep ma sempre la wait. Quando avrai capito molto bene
la wait rarissimamente puoi riusare la sleep ma meglio non usarla mai
ciao buon lavoro


Scusate ho letto sopra del multicore... è vero ora molti pc hanno dual
core o anche quad core..
Ma in java questa "ottimizzazione" su + core è fatta automaticamente
dalla jvm o ci sono librerie apposite da utilizzare ?

certo sei stato gentilissimo
grazie in finite .
mauro
"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:kd29r31ii95vk57q0...@4ax.com...


> Ho letto sul mnualke di java scritto da claudio de sio che è preferibile


 writes:
T> Scusate ho letto sopra del multicore... è vero ora molti pc hanno
T> dual core o anche quad core..
T> Ma in java questa "ottimizzazione" su + core è fatta automaticamente
T> dalla jvm o ci sono librerie apposite da utilizzare ?
Se la JVM modella i thread su quelli nativi, allora più CPU/core possono
eseguire più thread della JVMin parallelo...
-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                   e coltivatore diretto               not install
                               di software                   Debian"
a Cesare avrei detto di scrivermi | I would have told Caesar to write
a 
fn...@rat.vg
                    | me at 
fn...@rat.vg