J'étais récemment lisant des champs volatils sont le thread-coffre-fort parce que
Lorsque nous utilisons des mots-clés volatils avec une variable, tous les threads lus sa valeur directement de la mémoire et ne pas le mettre en cache
Cela m'a donc demandé, pour des champs non volatils, où le fil a-t-il lu sa valeur? Je pensais que tout était stocké en mémoire.
3 Réponses :
La déclaration que vous citez est une idée fausse. Je recommande l'article suivant: https: / /software.rajivprab.com/2018/04/29/myths-programmers-Believe-about-cpu-caches/
Si des variables volatiles ont été vraiment écrites / lues à la mémoire principale chaque fois, elles seraient horriblement lentes - les références de mémoire principale sont de 200x plus lentes que les références de cache L1. En réalité, des lectures volatiles (en Java) peuvent souvent être aussi bon marché en tant que référence de cache L1, mettant au repos une notion que les forces volatiles lit / écrit jusqu'à la mémoire principale. Si vous avez évité l'utilisation de volatiles en raison de problèmes de performance, vous auriez peut-être été victime des idées fausses ci-dessus.
L'article ci-dessus semble impliquer des champs même volatils pourraient être lus des caches L1. Est-ce vrai? Est ce fil-coffre-fort?
@Dave, sur un système multi-processeur typique (toutes les plates-formes HARWAY ne fonctionnent pas exactement de la même manière) chaque accès à la mémoire doit passer par un cache. Habituellement, la plate-forme propose des instructions spéciales pouvant être utilisées pour "synchroniser" les caches appartenant à différents processeurs. Un effet de volatile est, il oblige le JVM à exécuter ces codes OP spéciaux de synchronisation chaque fois que la variable volatile est accessible.
Chaque fil a une cache de la mémoire principale.
Un champ peut être déclaré volatile, auquel cas le modèle de mémoire Java Assure que tous les threads voient une valeur cohérente pour la variable p> blockQquote>
Par exemple, nous avons ce compteur statique qui n'est pas du fil de sécurité p>
xxx pré> si deux threads se littent et écrivez cette variable, il s'agira de ce p >
Main Memory - > static int counter; T1 - > Read and Writes directly from the memory T2 - > Read and Writes directly from the memory
Les variables non volatiles sont généralement stockées dans le cache de processeur ( par thread ) et ne sont périodiquement mis à jour périodiquement dans la mémoire principale.
Le modificateur volatil signifie que les données variables sont stockées dans la mémoire principale chaque fois qu'elle change et qu'il est donc toujours à jour lorsque un autre fil doit accéder à / le modifier.
Le JVM a-t-il un contrôle sur l'endroit où ces variables sont stockées? Je pensais que celles-ci étaient des instructions transmises au système d'exploitation, puis le système d'exploitation décide où stocker des choses.
D'après ce que je sais, ce qui n'est pas grand chose, je pense que la JVM indique au système d'exploitation à l'aide de bibliothèques natales que les variables doivent être "volatiles". Le terme varie à ce niveau.
Un registre n'est pas directement "Mémoire", il existe donc des moments qui ne sont pas de la mémoire où une variable peut être placée.
Un champ non volatile pourrait-il être stocké dans un registre? Si oui, comment est-ce déterminé?
Chaque variable statique et chaque variable de membre a un Place dans la mémoire principale, mais chaque CPU dans un système multiprocesseur est autorisé à conserver sa propre copie locale. C'est le "cache" qui répond ci-dessous parler. "Synchronisation" Les caches de différents processeurs dans le système sont chères. Par conséquent, la langue Java ne le fait pas, sauf à des points spéciaux où le programmeur sait qu'une valeur modifiée par un thread sera nécessaire dans un fil différent. Lorsque vous déclarez une variable d'être volatile , vous indiquez au compilateur dont vous avez besoin de chaque accès à la variable pour être synchronisé.
Salut @solomon, alors je suppose que la synchronisation des CPU de différents caches peut être coûteuse, mais n'est pas aussi coûteuse que d'accéder directement à la mémoire que l'une des réponses ci-dessous implique?
blog.thesoftwarecraft.com/2014/07/javas-modificateur. HT ML peut aider
@Dave, dans la plupart des architectures multiprocesseurs, il n'existe pas de "accéder directement à des choses". Tous les accès passent dans le cache. en.wikipedia.org/wiki/cache_(Computing)
@SolomonSlow Quel processeur a une telle chose que le cache non synchronisé et que l'ASM Instr utilisez-vous pour la synchroniser?