Newsgroup: it.comp.java
Titolo: Thread e wait(), notify(), notifyAll()

Ciao,
avrei bisogno che qualche volenteroso mi confermasse quando ho capito.
Un qualsiasi thread che esegue un wait() viene sospeso per un tempo 
indefinito. Il risveglio può avvenire solo nel caso in cui un altro 
thread chiami un metodo notify() o notifyAll(), con le dovute differenze.
Entrambe le operazioni (wait e notify) devono però avvenire nell'ambito 
dello stesso oggetto che offre uno o più metodi sincronizzati.
Quindi, supponiamo che ho un oggetto Obj che offre N metodi 
sincronizati. Un thread T1, ad un certo punto, chiama un metodo di Obj, 
che esegue una wait(). T1 va in stato di attesa, finchè un altro thread 
(supponiamo T2) non chiama uno degli N metodi di Obj che eseguono un 
notify(). A questo punto, T1 non viene risvegliato immediatamente, ma 
solamente dopo che T2 ha terminato il metodo sincronizzato (per 
salvaguardare la mutua esclusione).
Mi confermate quanto scritto? Purtroppo sono arrivato ad un punto morto 
e tanto più rileggo la documentazione, tanto meno ci capisco...
In linea di massima, il wait() ed i notify() notifyAll() non funzionano 
come i semafori in C (con i relativi metodi wait() e signal() ). Ovvero 
in Java con quei metodi non si potrebbe realizzare la mutua esclusione 
in modo diretto, senza ricorrere a strani magheggi. Giusto?
Grazie a chi avrà la pazienza di leggere e rispondere!

 Grazie a chi avrà la pazienza di leggere e rispondere!
Di nulla ^_^
-- 
Fermiamo Scientology prima che sia troppo tardi!!!
http://xenu.com-it.net
  ---  
http://xenu.freewinds.cx
(per rispondere personalmente leva IlDitoDalCulo)

 Di nulla ^_^
Fai conto che ti abbia offerto un boccale di birra ;-)
Grazie ancora!

 per la sincronizzazione e sospensione dei thread?
A dirti la verità non lo so nemmeno io, ma il dubbio mi è venuto leggendo
questo avviso (ripetutamente specificato in altre pagine della
documentazione):
-------
Note that this implementation is not synchronized. If multiple threads
access a list concurrently, and at least one of the threads modifies the
list structurally, it must be synchronized externally. (A structural
modification is any operation that adds or deletes one or more elements;
merely setting the value of an element is not a structural modification.)
This is typically accomplished by synchronizing on some object that
naturally encapsulates the list. If no such object exists, the list should
be "wrapped" using the Collections.synchronizedList method.
-------
Nota che dice "synchronizing on some object than naturally encapsulates the
list", e non "synchronizing on the list itself" (che sarebbe stato molto più
chiaro). Nel dubbio, ho sempre usato un oggetto parallelo (o anche this) per
proteggere gli accessi.
Appello al NG: se qualcuno avesse una motivazione plausibile per questa
affermazione, potrebbe illuminarci?
Grazie mille ^_^
-- 
Fermiamo Scientology prima che sia troppo tardi!!!
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx/


 > per la sincronizzazione e sospensione dei thread?
Nessuno te lo vieta.
Per sincronizzare puoi usare un qualsiasi oggetto, anche lo stack stesso.
È però buona norma (ti ricordi il vecchio detto latino "Divide ed impera"?)
usare sempre un oggetto diverso (un mutex distinto) e di cui tu hai
il completo controllo. E sarebbe ancora meglio(*) se questo mutex non fosse
pubblicamente accessibile, ma incapsulato e invisibile dentro una classe
wrapper che ti offre solamente i metodi che ti servono...
.. -> esattamente quello che ha fatto la Sun con le Collections
(vedi ad esempio l'implementazione di Collections.synchronizedList).
(*) Cosa succederebbe se un thread "cattivello"
   (o, magari, solamente mal codificato...)
   facesse un:
      synchronized(stack)
   oppure:
      synchronized(oggetto_parallelo_su_cui_sincronizzare_lo_stack)
   senza rilasciare mai il lock così ottenuto?
Quindi, riassumendo, puoi usare un qualsiasi oggetto (mutex)
per coordinare l'accesso ad un insieme di risorse condivise
da più thread. Però sarebbe meglio se questo insieme di risorse condiviso
fosse modellato come una classe al cui interno un membro privato
sarebbe il mutex su cui fare la sincronizzazione.
- Ciao
Inviato da 
www.mynewsgate.net

 - Ciao
Perfetto, ora mi risulta chiaro.
Usare un oggetto dedicato come mutex, magari incapsulato dentro una 
classe, migliora l'affidabilità del codice, anche se in definitiva posso 
fare come meglio credo.
Vi ringrazio molto per la spiegazione, chiara ed esauriente!
A presto!