Newsgroup: it.comp.java
Titolo: domanda su synchronized

Sempre per l'università sto scrivendo una piccola applicazione
client-server. Il server è ispirato molto al multithreaded echo server
esposto nel libro java network programming, quindi ogni volta che arriva
una connessione crea una nuova istanza di sè e passa tutto quello che
c'è da passare al suo clone.
Per effettuare il parsing delle richieste mi sono creato un oggetto
parser che al suo interno ha un metodo che effettua il tutto. Poiché
tale metodo accede ad una struttura dati e può essere chiamato da più
istanze del server l'ho dichiarato synchronized. Poiché è molto
importante che le richieste vengano gestite nello stesso ordine con cui
arrivano, il dichiarare il metodo synchronized me lo assicura? Oppure mi
assicura solo che lo stesso metodo non sia chiamato due volte
contemporaneamente?
-- 
Non c'è più forza nella normalità, c'è solo monotonia.

 arrivano, il dichiarare il metodo synchronized me lo assicura? Oppure mi
Per farla breve, il modificatore synchronized non consente la concorrenza di
accessi alla stessa risorsa (ovvero oggetto)....Ad esempio puoi
sincronizzare più thread su di un oggetto (ad es un Vector),  ed essere così
sicuro che mentre un thread esegue operazioni su quest'oggetto, gli altri
siano in attesa che il thread in possesso del "semaforo" lo
rilasci.......ehm...sono stato chiaro :)?
Penso che l'effettivo ordine con cui si eseguano le tue rischieste dipenda
dallo scheduling del sistema operativo, non è una cosa facilmente gestibile.
--
Giuseppe "Viper" Acito - 
vi...@amvi.it
T.te 21° Gruppo Volo virtuale AMVI - 
www.amvi.it
IVAO ID I-2102
ICQ # 69708049

 dallo scheduling del sistema operativo, non è una cosa facilmente gestibile.
quindi non c'è modo di assicurarsi che la gestione delle richieste sia
fifo? Nella mia applicazione è indispensabile, se ne vengono invertite
anche solo due posso prendere e buttare via tutto.
Quindi devo chiedere sui ng di linux per sapere come vengono schedulati
i processi?


Ti devo dire sinceramente che non so risponderti in modo esaustivo, dovremmo
entrare nell design della tua app..e vedere cosa si può fare...


 anche solo due posso prendere e buttare via tutto.
Suppongo che la risposta che tu (non) volevi sia contenuta in questa
sibillina frase:
If the wait set for the object is not empty, then some arbitrarily
chosen thread is removed from the wait set and re-enabled for thread
scheduling.
tratta dal Java Language Specification. La parola 'arbitrarily' è quella
che rovina tutto.
Ciao,
	Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 entrare nell design della tua app..e vedere cosa si può fare...
vabbò. Proverò a vedere se riesco a sistemare meglio la parte client
magari mettendoci una coda per essere sicuri di avere una gestione fifo.
Se proprio non ne vado fuori chiederò di nuovo sul ng.
Grazie


> Verissimo....non ci avevo pensato alla distinsione tra green e native :P
Neanche l'italiano: DISTINZIONE!!!!!
[super-OT] ps: la mia ragazza con questa storia delle s aspirate, oltre a
farmi parlare come un demente, mi sta facendo dimenticare tutte le z......


 che rovina tutto.
Era quello che stavo cercando di fargli capire con parole più ...dolci :P
Anche nel libro c'è una frase molto simile, che solo la disillusione ti fa
comprendere in pieno


 che rovina tutto.
accipicchia... Mi sembra strano che non sia possibile specificare un
modo di gestirsi i thread...


Stefano Reksten wrote:
aggiungo una riflessione: ma allora la bella classe stack che arriva di
libreria che ha tutti i metodi synchronized č una bufala...
Oh, se poi la jvm puň girarti i thread a suo piacimento....
-- 
Non c'č piů forza nella normalitŕ, c'č solo monotonia.

 libreria che ha tutti i metodi synchronized è una bufala...
No, perché? Tale classe ti garantisce unicamente che un unico thread
accederà ai metodi. 


 contemporaneamente?
" ... la seconda che hai detto "
Non bisogna mai fare affidamento al funzionamento di Thread in quanto
l'implementazione dipende dalla VM prescelta. Quindi fatti una coda sul server.
Se puo' esserti utile, le variabili dei metodi non hanno problemi di accesso
non sincronizzato (ogni thread ha una sua copia) a differenza degli attributi
di un oggetto.
Saluti
-- 
a     l     e     f
'     '     '     '

 accederà ai metodi.
sì, ma se mi vengono accodate tutte le richieste di accesso ai metodi e
poi mi vengono arbitrariamente riordinate rischio di avere un lifo che
non funziona proprio tanto bene...
o no?


 o no?
Perché? Se due client vogliono fare push(5) e push(6)
contemporaneamente, uno dei due lo dovrà fare prima dell'altro e quando
andrai a fare pop() otterrai comunque l'ultimo elemento che è stato
inserito. Io direi che funziona esattamente come dovrebbe.


 inserito. Io direi che funziona esattamente come dovrebbe.
ma scusa...
supponi di avere 3 push. Il primo viene eseguito e gli altri due
accodati per essere effettuati. Se i thread che vogliono usare il metodo
mentre sono accodati possono essere riordinati arbitrariamente allora
non è detto che al pop otterrò l'oggetto che è stato passato come
parametro all'ultimo metodo chiamato, ma l'ultimo aggiunto allo stack
che può non essere lo stesso proprio perché mentre sono in coda le
chiamate ai metodi possono essere "riordinate".
O no?


 chiamate ai metodi possono essere "riordinate".
Infatti. Dipende dalla politica dello scheduler risvegliare un task o
l'altro. Non è detto che per forza l'ultimo thread che si è messo in
coda per inserire un oggetto in uno stack sarà per forza l'ultimo ad
inserirlo effettivamente.
