Discussion :

[miya]

Bonjour,

Je lisais quelques articles autour des threads en java, et je me posais une question sur la visibilité mémoire.

J'utilise volatile, pour garantir que tous mes threads puissent voir les modifications associées à mon attribut. Idem sur la synchronisation (pour la visibilité) (avec mutex en plus).

Je lisais dans un article : "toutes les variables qu'il a modifiées sont publiées auprès de tous les autres threads qui les connaissent".

Ma question (peut-être bête) quand il parle de publier, c'est une publication au sens "les changements dans la heap" ? Ou d'un plus bas niveau comme sur le processeur ?

Dites moi si je ne suis pas clair dans ma question.
Merci d'avance

[thelvin]

Pas très clair comme question, quoi le microprocesseur ?

Le microprocesseur a un cache tout comme toute l'architecture, et donc quand on veut aller lire des données publiées il faut resynchroniser le cache, ce qui est bien géré par l'emploi de volatile ou de synchronized. De même pour tous les caches de tous les niveaux.
C'est pour ça qu'on dit que les synchronisations ont un prix et qu'il faut pas en faire n'importe comment. D'un autre côté, il en faut pour faire du multithreadé, qui apporte beaucoup.

[miya]

Ok donc il parle bien d'une publication au niveau du microprocesseur.

Avec les architectures multi-coeurs, chaque coeurs possède ces propres caches (L1...L3) et registre. Les threads étant répartis sur chacun des coeurs, ils stockent en cache des valeurs (pour des questions d'optimisation). Si je synchronise, je force à ne pas optimiser ses valeurs (donc à les mettre en cache). Donc si je comprends bien ta réponse, il publie la valeur dans chacun des caches des coeurs ?

[thelvin]

"Publication" n'est pas vraiment le mot. Il indique que cette portion de la mémoire a été modifiée par un cœur, et que les caches des autres ne sont plus synchrones avec la mémoire centrale.
Mais les autres ne s'en soucieront qu'au moment opportun, genre au prochain accès à cette zone.

Ce que je veux dire c'est que le travail d'un cœur n'a pas d'effet direct sur les caches des autres cœurs, il n'aura qu'un effet a posteriori s'ils se retrouvent concernés à un moment. Et notamment ils prendront tous les changements d'un coup au lieu de l'un après l'autre*.

* Enfin c'est le grand classique. Il y a des architectures sans cache.

[Gugelhupf]

L'utilité d'employer le mot clé volatile sur un attribut, c'est que celui-ci est susceptible d'être utilisé dans plusieurs portion de code exécuté par un thread.

Le problème en Java, c'est que les opérations sur les variables ne sont pas forcément atomiques (les valeurs sont conservés dans un cache dans un but d'optimisation je crois), du coup si tu as une variable qui a une valeur X à un instant T1 et Y à un instant T2 dans Thread A, cette variable pourrait toujours avoir la valeur X à l'instant T2 dans le Thread B.

Je pense que cette histoire de "publication" revient à dire en gros : Thread A a modifié la variable volatile et sa valeur actuelle sera "publié" à Thread B.

PS : adiGuba est plusieurs fois intervenu sur ce type de sujet, n'hésite pas à effectuer une petite recherche

[miya]

Merci pour vos réponses.

@Gugelhupf Pardon si je n'ai pas été clair, mais je pense avoir compris la fonction de volatile avec les threads au sein d'une application java.

En faite, j'aurai aimé comprendre comment côté processeur, et du multi-coeur, cela fonctionnait.

Après avoir lu les 4 premiers chapitre de Java Concurrency, ca n'est pas expliquer. Peut être dans les chapitres suivants.

[tchize_]

ca ne sera a priori expliqué nulle part. Et pour cause, la jvm est concue pour t'abstraire de l'architecture hardware. C'est aux personnes implémentant la jvm (donc oracle, open jdk, ibm) de faire en sorte que la jvm respecte les spécifications. Si tu veux des détails techniques, il y en a dans le java language specification et dans le java virtual machine specification. Toi, en tant que dev, tout ce que tu dois savoir, c'est c'est le comportement de synchronized quand on rentre dans un bloc et quand on en sort, ainsi que le comportement de volatile

[thelvin]

Oui enfin c'est pas plus mal de savoir que sur les architectures utilisant des caches, ça va sûrement invalider ces caches et donc il y a une question de performance. Et que sur d'autres architectures, ça va synchroniser d'une manière ou d'une autre et ça va sûrement poser des questions de performance aussi.

Il faut savoir synchroniser avec parcimonie, sinon on synchroniserait tout et la notion n'aurait pas de sens.

[adiGuba]

Salut,



Grosso-modo la JVM va faire toute sorte d'optimisation sur le code, et en particulier elle peut utiliser un cache local (registre CPU ou autre) pour les données utilisées par le thread.
Du coup si deux threads manipulent la même variable en même temps, il est possible qu'ils n'aient pas accès aux mêmes valeurs, et certaines modifications peuvent passer inaperçu.



Les outils de synchronisation permettent de donner une relation "happen-before" entre deux instructions situés dans différents threads.
S'il y a une relation "happen-before" entre deux instructions, alors tu es sûr que les modifications apportées seront visible même si les threads sont différents (et donc que les caches seront mis à jour).

Les divers outils de synchronisation (synchronized, volatile, mais aussi les Lock, Thread.join(), etc.) permettent donc de définir une telle relation.

• Lorsque tu rentres dans un bloc synchronized, tu es sûr de voir les modifications apportées avant la fin du dernier bloc synchronized sur le même verrou.
• Lorsque tu lis une variable volatile, tu es sûr de voir les modifications apportées à la dernière modification de cette même variable.
• Lorsque tu fais un join() sur un thread (ie : attendre que le thread se termine), tu es sûr de voir les modifications effectuées par le thread en question.
• etc.

Bref lorsqu'une relation "happen-before" survient, le cache du thread est vidé pour prendre en compte les modifications apportés par les autres threads.


[edit] Pour plus de détail, le chapitre 17 des spécifications est très complet : http://docs.oracle.com/javase/specs/...ml/jls-17.html


a++

[miya]

Grosso-modo la JVM va faire toute sorte d'optimisation sur le code, et en particulier elle peut utiliser un cache local (registre CPU ou autre) pour les données utilisées par le thread

Je n'ai peut-être pas bien compris, mais quand vous parlez de "elle" et d'un registre CPU, c'est au niveau de la JVM ? Chaque threads possède leur stack + un cache, et lorsque l'on "publie" l'information, la JVM se charge de mettre à jour tous les caches des threads ?

Pour compléter vos propros, l'article est intéressant : http://tinyurl.com/phqcudv

[adiGuba]

Je n'ai peut-être pas bien compris, mais quand vous parlez de "elle" et d'un registre CPU, c'est au niveau de la JVM ? Chaque threads possède leur stack + un cache, et lorsque l'on "publie" l'information, la JVM se charge de mettre à jour tous les caches des threads ?

Grosso-modo oui !

Le stack ne concerne que les variables locales, et n'est donc pas concerné par le multithreading.
Cela concerne uniquement les objets dans le heap.

a++