Discussion :

[zenux]

Bonjour,

J'ai ce code source (Main.java):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
class MyThread extends Thread {
 
	private Main main;
 
	public MyThread(Main main){
		this.main = main;
	}
 
	public void run() {
		main.addOne();
		main.addOne();
	}
}
 
public class Main{
 
	public double a = 0.0;
 
	public synchronized void addOne(){
		a += 1.0f;
	}
 
	public static void main(String []args){
		Main main = new Main();
 
		MyThread t1 = new MyThread(main);
		MyThread t2 = new MyThread(main);
		t1.start();
		t2.start();
 
		try{
			t1.join();
			t2.join();
		}catch(InterruptedException e){};
 
		System.out.println("A value:" + main.a);
	}
}

Est-ce que le résultat sera toujours 4.0 ?
J'ai mis le mot clef 'synchronized' et donc je suis sûr que l'opération d'ajout sera faite de façon atomique.
Par contre, je n'ai pas mis le mot clef 'volatile' sur la variable 'a'. Donc, si j'ai bien compris la variable 'a' pourrait se retrouver déjà incrémenté de 1.0 dans le cache CPU de la thread 1 tandis que la thread 2 va incrémenter 'a' en se basant sur sa valeur se trouvant en RAM. Du coup, je pourrais avoir en sortie 3.0 ?

Merci d'avance.

[thelvin]

Hello,

Est-ce que le résultat sera toujours 4.0 ?
J'ai mis le mot clef 'synchronized' et donc je suis sûr que l'opération d'ajout sera faite de façon atomique.

Oui et oui.

Par contre, je n'ai pas mis le mot clef 'volatile' sur la variable 'a'. Donc, si j'ai bien compris la variable 'a' pourrait se retrouver déjà incrémenté de 1.0 dans le cache CPU de la thread 1 tandis que la thread 2 va incrémenter 'a' en se basant sur sa valeur se trouvant en RAM. Du coup, je pourrais avoir en sortie 3.0 ?

Non. Comme son nom l'indique, synchronized s'occupe de synchroniser les caches. Tu n'as pas besoin de t'occuper d'eux si tu utilises synchronized correctement, ce qui est le cas ici.
Cela en fait donc un mécanisme coûteux, mais simple.

volatile n'est utile que si tu n'utilises pas déjà synchronized pour gérer le multithread.

[zenux]

Merci beaucoup.
Je m'en doutais un peu mais je voulais être sûr.

[Gugelhupf]

Bonsoir,

volatile n'est utile que si tu n'utilises pas déjà synchronized pour gérer le multithread.

Personnellement je préciserais tout de même le mot-clé volatile pour plusieurs raisons :

• Il est possible d'utiliser l'attribut en question dans un environnement multithread hors d'un bloc synchronized même si ce dernier était prévu à la base pour être utilisé dans un bloc synchronized.
• Il est possible d'employer les Lock à la place de synchronized.
• Même si préciser volatile n'est pas utile dans le cas d'un bloc synchronized, cela ajoute de la lisibilité.

[thelvin]

Il est possible d'utiliser l'attribut en question dans un environnement multithread hors d'un bloc synchronized même si ce dernier était prévu à la base pour être utilisé dans un bloc synchronized.

Ah ? synchronized ne suffisait pas, au départ ? Ça remonte à quelle version, tu saurais pointer la différence ?

Même si préciser volatile n'est pas utile dans le cas d'un bloc synchronized, cela ajoute de la lisibilité.

?
Tu as un exemple ?

[Gugelhupf]

Ah ? synchronized ne suffisait pas, au départ ? Ça remonte à quelle version, tu saurais pointer la différence ?
Tu as un exemple ?

Voici mon exemple :

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
/**
 * Classe créée par Jean le XX/XX/2009 
 * Note : La classe suivante est utilisée dans un environnement multithread
 */
class MaClasse{
 
    /**
      * Ajouté par Jean le XX/XX/2009
      */
    private UneAutreClasse c;
    public synchronized void methode1(){
        // Utilisation de c
    }
 
    /* Bien plus loin dans le code, plus tard dans le temps, Marc reprend le projet */
 
    /**
      * Ajouté par Marc le XX/XX/2016
      */
    private Lock lock = new ReentrantLock();
    public void methode2(){
        if(lock.tryLock()){
            try {    
                // Utilisation de c
            } finally { 
                lock.unlock(); 
            }
         } 
    }
 
}

Ici Marc reprend le projet, sait qu'il existe un attribut c utilisé un peu partout et qu'il peut utiliser dans son ajout, mais ne fait pas attention concernant le manque du mot-clé volatile, parce que Jean utilise seulement cet attribut dans des blocs synchronized. La question est : perd-t-on quelque chose à ajouter ce mot-clé si on sait que ce notre classe sera utilisé dans un environnement multithread ?

[thelvin]

J'en sais trop rien. Mon premier réflexe quand je vois quelque chose est de me demander pourquoi c'est là. Où est cette utilisation hors-synchronized de la variable qui justifie de la rendre volatile. Qu'est-ce que j'ai raté dans ce code et cela ne devrait-il pas me pousser à revoir ce que je cherchais à faire, cette variable étant utilisée dans des cas où volatile suffit, ses contraintes d'utilisation ne sont-elles pas plus compliquées que je ne le croyais ?
C'est un coup à poursuivre des chimères. Si on veut un code maintenable, il faut que des notions comme "bien plus loin, sans aucun rapport" ça n'existe pas, et que la chaîne de responsabilité des actions à faire soit déléguée à plus de classes séparées.

Maintenant j'ai jamais été bien convaincu par volatile. Franchement, à quels moments dans un programme, peut-on vraiment se contenter d'un simple read atomique d'une seule variable ?
En principe si on est vraiment parvenu à se convaincre que c'est suffisant, prendre la décision d'aller rendre la variable volatile devrait aller de soi puisqu'on est le premier à pouvoir se contenter de ça.
Et si, finalement, elle était déjà volatile pour d'autres raisons, ce n'est pas un problème.

[joel.drigo]

Est-ce que la décision de rendre volatile la variable a ne serait pas par rapport à sa portée. Ici, ce qui me gène, c'est d'avoir un attribut a public : si son incrémentation est correctement synchronisée dans le code de la classe, rien n'empêche n'importe qui d'en modifier la valeur ou de la lire de manière non synchronisée, alors qu'il est assez facile de ne pas se rendre compte que sa modification est synchronisée dans la classe. A mon avis, dès qu'un attribut est manipulé dans des blocs (ou méthodes) synchronisé(e)s, on devrait empêcher tout accès exterieur autre en limitant sa portée, ou rendre éventuellement volatile l'attribut.

[Gugelhupf]

Les deux questions que je me pose avant de préciser le mot-clé volatile sont :

1. Ma classe sera utilisé dans un environnement multithread ?
2. L'attribut pourra éventuellement être réaffecté (ps : attribut = autreChose;) après son initialisation dans le constructeur ? (cf: attribut non-final)

Si oui pour les deux questions, alors je précise ce mot-clé. Bien sûr si notre attribut est un Atomic ou qu'il est toujours utilisé dans un bloc synchronized on ne rencontrera pas de problème, mais il existe trop de facteurs/situations, des erreurs d'inattention qui pourraient provoquer des erreurs sans même que l'on s'en rende compte par la suite.