Selon Ultrich Drepper, qui est un expert infâme ancien mainteneur de glibc, "non affecté dans le segment de données normal, chaque thread a sa propre zone distincte où ces variables sont stockées.Les variables peuvent avoir des initialiseurs statiques. Les variables locales sont adressables par tous les autres threads mais, sauf si un thread passe un pointeur vers une variable locale à ces autres threads, les autres threads ne peuvent trouver cette variable. n'est pas un problème, sauf si le programme crée artificiellement un problème. "
Si vous étudiez, Memory part 6: More things programmers can do les variables locales de thread, si un pointeur est passé, pourraient accéder à la même ligne de cache.
Pour éviter ce problème, ne passez pas les adresses en question. Une technique spécifique de regroupement de variables rw fréquentes pour partager une ligne de cache dans une structure est décrite, avec remplissage pour AVOID plusieurs threads écrivant sur la même ligne de cache lorsque vous n'utilisez pas TLS, tant que les pointeurs de variable __thread ne sont pas utilisés par d'autres threads, Le rebond de la ligne de cache doit être évité. Heureusement, les implémenteurs de linker connaissent l'architecture CPU, vous ne pouvez pas choisir où, en & espace d'adressage physique virtuel, la mémoire locale multipliée est allouée, il devrait être présumé que plus les concepteurs de CPU font un travail raisonnable d'éviter les performances problèmes dus à de faux conflits. Vous auriez les mêmes problèmes qui se produisent par accident entre les processus séparés, threads nevermind si l'associativité du cache rebondissait était un problème commun.