[Java 1.5.x] volatile

[71104]

in Java 1.5.qualcosa volatile applicato ad un oggetto rende "volatile" (cioè non cachato, se ho capito bene) il riferimento all'oggetto o il contenuto dell'oggetto stesso? spero di aver posto chiaramente la domanda :help:

EDIT: ah, e nel caso fosse la seconda ipotesi cosa succede se il riferimento è null? e se esistono più riferimento per quell'oggetto? tipo, qui:

Object volatile obj = new Object();
Object a = obj;
Object b = a;
// ecc.

cosa di preciso è volatile? :help:

[^TiGeRShArK^]

in Java 1.5.qualcosa volatile applicato ad un oggetto rende "volatile" (cioè non cachato, se ho capito bene) il riferimento all'oggetto o il contenuto dell'oggetto stesso? spero di aver posto chiaramente la domanda :help:

EDIT: ah, e nel caso fosse la seconda ipotesi cosa succede se il riferimento è null? e se esistono più riferimento per quell'oggetto? tipo, qui:

Object volatile obj = new Object();
Object a = obj;
Object b = a;
// ecc.

cosa di preciso è volatile? :help:
il contenuto.....
Il riferimento in java te lo puoi anke dimenticare dato ke il passaggio non è nè x valore nè x riferimento ma bensì x copia del riferimento :asd:
EDIT: non ho capito la domanda del tuo EDIT :fagiano:

[^TiGeRShArK^]

Ecco una sintetica spiegazione:

The volatile modifier requests the Java VM to always access the shared copy of the variable so the its most current value is always read. If two or more threads access a member variable, AND one or more threads might change that variable's value, AND ALL of the threads do not use synchronization (methods or blocks) to read and/or write the value, then that member variable must be declared volatile to ensure all threads see the changed value.

[71104]

eccoti quaaaa, ti aspettavo, te o PGI-Bis :D

il contenuto..... perfect; ma allora nel codice di esempio di prima l'oggetto è volatile? perché quell'oggetto viene memorizzato in 3 diverse variabili (obj, a e b) di cui solo uno è volatile (obj)... forse l'oggetto diventa volatile se e solo se lo è la prima variabile a cui viene assegnato il suo riferimento, ovvero quella che riceve il risultato della chiamata a new? :mbe:

[PGI-Bis]

La dico rapida.

Circa il dubbio volatile vale per tutto l'oggetto, la risposta è no, volatile vale solo per il valore delle variabili così dichiarate. L'insieme di campi appartenenti ad un oggetto non appartiene al concetto di valore di un riferimento (è un puntatore, ha dentro un numero e solo quel numero è "valore" del riferimento).

Se un l'oggetto X, campo volatile, ha a sua volta tre campi A, B, C e questi non sono a loro volta volatile, l'accesso ai campi A, B, C non subisce le restrizioni del modello di memoria, cioè non è garantito che il Thread che accede ad A, B, C tramite x veda gli ultimi valori che un altro Thread abbia applicato ad A, B, C.

Al fine di garantire che il valore di A, B, C, campi di X, sia l'ultimo che un qualsiasi Thread abbia loro assegnato non basta che X sia volatile ma devono esserlo anche A, B, e C.

Più in generale, ciò che devi fare è adottare quei comportamenti che ti garantiscano l'esistenza di una relazione accade-prima tra la scrittura di un valore in una variabile e la lettura del valore di quella variabile.

[^TiGeRShArK^]

Più in generale, ciò che devi fare è adottare quei comportamenti che ti garantiscano l'esistenza di una relazione accade-prima tra la scrittura di un valore in una variabile e la lettura del valore di quella variabile.
Infatti, è proprio questo il punto nodale ke è stato reso possibile grazie alla riscrittura delle specifiche del memory model in java 5.
Prima era anke possibile, ma il suo funzionamento non era garantito x via delle specifiche alquanto lacunose ke in pratica lasciavano + libertà a ki implementava la virtual machine causando potenziali problemi.
Cmq ti consiglio di andare a riprendere il thread ke avevi aperto l'altra volta sul wait notify e di leggerti i link postati da thebol (se non sbaglio) ke parlavano proprio di questo e della relazione Happens-Before (accade-prima fa un pò kakare in italiano devo dire :asd: ).
Inoltre visto ke a quanto ho capito stai combattendo con i thread.... prova a dare un'okkiata a questa presentazione....
è un pò (MOLTO) sintetica...
Ma se nn capisci qualkosa kiedi pure ke qualcosina dovrei ancora ricordarmi ;)
http://roma.javaday.it/javaday/index.jsp?page=program.html

[PGI-Bis]

Questo è quello che c'era prima:

http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28330

e questo è quello che c'è adesso:

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7

Ci sono due cose certamente cambiate: una riguarda i volatile e una i final. Che per altro si capisce bene dai draft del JSR133 (perchè lo dicono all'inizio) e malissimo nella final release (secondo link). Il resto a me pare un cumulo di tecnicalità sulla cui esatta interpretazione non mi pronuncerei per evitare imbarazzi :D.

[71104]

ehm, scusate ma...

il contenuto.....
Se un l'oggetto X, campo volatile, ha a sua volta tre campi A, B, C e questi non sono a loro volta volatile, l'accesso ai campi A, B, C non subisce le restrizioni del modello di memoria, cioè non è garantito che il Thread che accede ad A, B, C tramite x veda gli ultimi valori che un altro Thread abbia applicato ad A, B, C.
voi geniacci vi siete un attimino contraddetti :D
sto volatile che fa? ora comunque vado anche a rivedermi quello che aveva scritto thebol l'altra volta perché in effetti ricordo che ne parlò :)

[71104]

Inoltre visto ke a quanto ho capito stai combattendo con i thread.... grazie per il link, ma in realtà il programma che sto facendo per un esame universitario non ricopre solo l'aspetto multithreading; di tutti gli aspetti coperti però il multithreading è il più difficile :muro:

parlando in generale indipendentemente dal linguaggio (Java, C#, C, C++, quello che ti pare) il multithreading è semplicemente difficile: alza la complessità dei sorgenti di un software in maniera paurosa, e non solo a livello concettuale ma anche parlando banalmente di complessità ciclomatica (più variabili, più if-for-while-try, ecc.)

[PGI-Bis]

vi siete un attimino contraddetti :D

Oh, è una normalissima divergenza scientifica che si risolve con un banalissimo atto di civiltà.

HO RAGIONE IO! (e giù a schiaffoni :D)

[^TiGeRShArK^]

Oh, è una normalissima divergenza scientifica che si risolve con un banalissimo atto di civiltà.

HO RAGIONE IO! (e giù a schiaffoni :D)
:mbe: tra l'altro mi sfugge la contraddizione dato ke nel mio secondo post avevo specificato ke x contenuto intendo il valore della variabile volatile :mbe:

[lovaz]

Semi OT
Comunque in java il passaggio e' per riferimento, escludendo
primitivi e oggetti passati via RMI.

[^TiGeRShArK^]

Semi OT
Comunque in java il passaggio e' per riferimento, escludendo
primitivi e oggetti passati via RMI.
eh no :D
Non è per riferimento, ma è un passaggio per copia del riferimento :D
Ai tempi sul forum della sun c'è stata una discussione piuttosto lunghetta sull'argomento :asd:

[lovaz]

Beh, e' logico che il riferimento in qualche modo lo devi passare... :D
Se mi dai un esempio di "vero" passaggio per riferimento -
in qualsiasi linguaggio - posso vedere anche io. ;)

[^TiGeRShArK^]

Myth: "Objects are passed by reference, primitives are passed by value"

Some proponents of this then say, "Ah, except for immutable objects which are passed by value [etc]" which introduces loads of rules without really tackling how Java works. Fortunately the truth is much simpler:

Truth #1: Everything in Java is passed by value. Objects, however, are never passed at all.

That needs some explanation - after all, if we can't pass objects, how can we do any work? The answer is that we pass references to objects. That sounds like it's getting dangerously close to the myth, until you look at truth #2:

Truth #2: The values of variables are always primitives or references, never objects.

This is probably the single most important point in learning Java properly. It's amazing how far you can actually get without knowing it, in fact - but vast numbers of things suddenly make sense when you grasp it.

Questo spero spieghi un pò meglio le cose ;)
ank'io i primi tempi con java credevo ke le cose stessero come dici tu..
ma mi sono dovuto ricredere :D
In questo link viene spiegata tutta la questione (abbastanza filosofica tra l'altro :asd: ) per bene:
http://www.yoda.arachsys.com/java/passing.html

[lovaz]

Questione interessante...

Certo, e' filosofica, come molte cose informatiche :D

E in effetti non sono totalmente d'accordo. Cerco di spiegarmi.

Partiamo dal fatto che la semantica di passaggio per riferimento consente
di operare sull'entita' (non lo chiamo oggetto per non creare confusione)
di cui dispongo all'interno della funzione, in modo da alterare l'entita' esterna.
Su questo si puo' benissimo non essere d'accordo, e' filosofia...

Ora io, per "operare su un oggetto" intendo chiamare i suoi metodi,
assegnare proprieta' come i campi pubblici, eccetera - in pratica alterarne lo stato.

Quando faccio un assegnamento - come fanno nel primo esempio dell'articolo
che hai linkato, che ovviamente non funziona - io dico: "butta via l'oggetto vecchio,
e assegna a questo riferimento un altro oggetto".
Questo io non lo chiamo "operare su un oggetto" -
ma ribadisco che si puo' benissimo dissentire.

Secondo il mio punto di vista dipende tutto dal livello di analisi considerato.

A "basso livello" i valori sono effettivamente passati per valore -
come potrebbe essere altrimenti?

Ad "alto livello" gli oggetti che considero all'interno della funzione sono gli
stessi che stanno fuori - sempre IMHO.

Ovviamente esclusi i primitivi e gli oggetti passati in invocazioni remote,
per i quali il riferimento perde di significato.

[^TiGeRShArK^]

Questione interessante...

Certo, e' filosofica, come molte cose informatiche :D

E in effetti non sono totalmente d'accordo. Cerco di spiegarmi.

Partiamo dal fatto che la semantica di passaggio per riferimento consente
di operare sull'entita' (non lo chiamo oggetto per non creare confusione)
di cui dispongo all'interno della funzione, in modo da alterare l'entita' esterna.
Su questo si puo' benissimo non essere d'accordo, e' filosofia...

Ora io, per "operare su un oggetto" intendo chiamare i suoi metodi,
assegnare proprieta' come i campi pubblici, eccetera - in pratica alterarne lo stato.

Quando faccio un assegnamento - come fanno nel primo esempio dell'articolo
che hai linkato, che ovviamente non funziona - io dico: "butta via l'oggetto vecchio,
e assegna a questo riferimento un altro oggetto".
Questo io non lo chiamo "operare su un oggetto" -
ma ribadisco che si puo' benissimo dissentire.

Secondo il mio punto di vista dipende tutto dal livello di analisi considerato.

A "basso livello" i valori sono effettivamente passati per valore -
come potrebbe essere altrimenti?

Ad "alto livello" gli oggetti che considero all'interno della funzione sono gli
stessi che stanno fuori - sempre IMHO.

Ovviamente esclusi i primitivi e gli oggetti passati in invocazioni remote,
per i quali il riferimento perde di significato.

ehm..
no...
è proprio questo il punto..
In C passando una qualsiasi cosa per riferimento se tu modifichi all'interno della funzione "ricevente" questa cosa che gli hai passato allora vedrai propagate le modifiche anche in altri punti del programma che non hanno niente a che vedere con questa funzione.
Se tu in Java passi un oggetto ad un metodo, non stai facendo altro che passare la copia di un riferimento.
In questo modo avviene la situazione descritta in questo codice:

public void tricky(Point arg1, Point arg2)
{
arg1.x = 100;
arg1.y = 100;
Point temp = arg1;
arg1 = arg2;
arg2 = temp;
}
public static void main(String [] args)
{
Point pnt1 = new Point(0,0);
Point pnt2 = new Point(0,0);
System.out.println("X: " + pnt1.x + " Y: " +pnt1.y);
System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);
System.out.println(" ");
tricky(pnt1,pnt2);
System.out.println("X: " + pnt1.x + " Y:" + pnt1.y);
System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);
}

il suo output è il seguente:

X: 0 Y: 0
X: 0 Y: 0
X: 100 Y: 100
X: 0 Y: 0

ebbene...
cosa è accaduto?
I valori del primo punto sono stati correttamente modificati, come avviene nel passaggio per riferimento normale, ma lo swap non è stato effettuato perchè in java NON esiste il passaggio per riferimento ma solo quello x valore.
Per questo infatti i riferimenti che la funzione vede non sono altro che copie dei riferimenti originale e di conseguenza lo swap non può funzionare in quanto sta operando su delle copie dei riferimenti e non sui riferimenti originali.
Per questo è totalmente sbagliato dire:

Ad "alto livello" gli oggetti che considero all'interno della funzione sono gli
stessi che stanno fuori

Perchè in realtà il contenuto degli oggetti è uguale ma gli oggetti non sono uguali in toto in quanto il riferimento visto è solo la copia di quello originale.
Scrivendo quel pezzo di codice in C e utilizzando il passaggio per riferimento vedresti lo swap effettuato correttamente e quindi in output avresti:

X: 0 Y: 0
X: 0 Y: 0
X: 0 Y: 0
X: 100 Y: 100

Spero ke ora sia + kiaro ;)

[71104]

:mbe: tra l'altro mi sfugge la contraddizione dato ke nel mio secondo post avevo specificato ke x contenuto intendo il valore della variabile volatile :mbe: OOOOOOOOOOra ho capito, grazie! :read:

[lovaz]

Tiger, qui la discussione sul passaggio di parametri è OT,
quindi, visto che la questione mi interessa, ho aperto una discussione apposita qui:
http://www.hwupgrade.it/forum/showthread.php?t=1364021