La concurence en Java

en faite je suis entrain de lire le livre java concurrence, et les choses deviennent difficile pour raisonner.

voila un exemple sur le livre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class NoVisibility { private static boolean ready; private static int number; private static class ReaderThread extends Thread { public void run() { while (!ready) Thread.yield(); System.out.println(number); } } public static void main(String[] args) { new ReaderThread().start(); number = 42; ready = true; } }

---

d’après l'auteur le programme peut afficher 0 ou 42 ou rien affiché.
pour moi le programme doit toujours afficher 42 puisque le 2ème thread donne la main au thread principale pour initialisé la valeur number à 42.

si quelqu'un peut me clarifier la situation ou le programme va afficher 0 et une boucle infinie et merci

Bonjour,

le principe est simple, lorsque tu lances ton thread à ce niveau:

Code:

---

new ReaderThread().start();

---

il y a déjà un autre thread qui a été lancé par le void main, donc on ne sait pas quel thread sera exécuté en premier car c'est la JVM qui gére ça

afficher 42 => le cas le plus évident, je ne m'étends pas dessus :)

ne rien faire => ready n'est pas volatile, il n'y a pas de bloc de synchronisation, donc tu peux avoir le thread "reader" qui ne va pas lire dans le static la nouvelle valeur, mais se contente de celle qu'il a en cache dans son contexte. Il faut savoir que chaque thread a son propre contexte et que, pour des raisons de performances (c'est très couteux de partager la mémoire centrale entre deux CPUs ou deux cores) certaines données peuvent être conservées par le compilateur dans des registres ou la stack locale au thread. Comme tu n'a indiqué nulle part que tu faisait de la concurrence (mot clé volatile ou synchronized), le compilateur en conclue que rien dans ta boucle ne peux modifier reader et que donc, il n'y a pas de raison d'aller le relire.

Au final, t'as un thread qui vois ready à false 100% du temps

0 => Pas la même raison, (number n'est jamais lu tant que ready false, donc pas de cache). Par contre, dans ton main, le compilateur (ou même carrément le processeur x86!!!) vois deux instructions totalement indépendantes (ready ne dépend pas de number, number ne dépend pas de ready) et donc en conclue "je peux changer leur ordre si c'est plus performant". La solution ici est encore, depuis java 5, de mettre volatile sur ton booléen. L'écriture dans une variable volatile est comprise par le compileur comme une délimitation, ce qui se trouve en amont ne peux pas être déplacé en aval. Et donc tes deux instructions ne peuvent pas être réordonnées.

tchize_
bien expliqué :ccool: même dans le livre ce n'est pas bien clarifié comme vous avez fait, peut être à cause de la traduction de l'anglais vers le français du livre.

hbennou
merci comme même mais c'est pas si facile ce que j'ai posé comme problème.