Pourquoi faire une synchronisation sur type primitif

Bonjour,

Dans la classe Thread j'ai vu ce code et je ne comprends pas pourquoi il y a besoin de synchroniser l'incrémentation d'un type primitif ?

Code:

---

1 2 3 4 5 6

/* For autonumbering anonymous threads. */   private static int threadInitNumber; private static synchronized int nextThreadNum() { return threadInitNumber++; }

---

et dans le constructeur

Code:

---

1 2 3

public Thread(Runnable target) { init(null, target, "Thread-" + nextThreadNum(), 0); }

---

Qu'est-ce que j'ai oublié de savoir ? ou pas compris ?

Merci à tous et à toutes pour vos réponses

l'incrémentation n'est pas un opération atomique: on lit une valeur, on l'incrémente et on l'écrit ... zou au milieu vl'a t'il pas qu'un vilain canard de Thread vient s'interposer :aie:
maintenant pour ce genre de chose on utilise un AtomicInteger

Et même si c'était atomique, ça résout pas les problèmes plus graves : les caches mémoire pas synchronisés, le réordonnancement...

Merci a vous pour vos réponses.

Je suis déçu. Je pensais que i++ se faisait en une seule instruction avec inc en assembleur.

Si la variable peut être modifié par un autre thread faut la déclarer volatile pour éviter l'utilisation du cache et forcé la relecture oui je savais merci.

Donc rien n'est (automatiquement) atomique en java faut penser comme ca en fait...

Alors:

- i++ se fait bel et bien avec une seule instruction inc, si i est une variable locale (donc dans la pile). Mais le processeur java étant en pure pile, si i n'est pas dans la pile il va bien sûr falloir un load et un store.

- une instruction, ça ne veut pas dire atomique. Il faut la déclarer atomique pour qu'elle le soit, et c'est plus cher. Il n'y a pas de magie, pour incrémenter une valeur dans la mémoire centrale, il faut récupérer cette valeur, calculer ce qu'elle vaut incrémentée, et stocker le résultat.

- en Java, est atomique une lecture ou une écriture d'une référence d'objet, d'un boolean, d'un byte, d'un short, d'un char, d'un int et d'un float. En pratique sur les machines 64-bit c'est aussi le cas des long et des double, mais Java ne le garantit pas, du fait de l'existence du 32-bit. Il est très peu probable que les autres langages promettent plus sur des machines qui ne le font pas par elles-mêmes. Ce serait assez déplorable en performance.