La question posée concerne le comportement d'un thread C# lors de la lecture d'une valeur booléenne modifiée sur un autre fil de discussion. Certains articles suggèrent que le thread de lecture peut mettre en cache l'ancienne valeur, conduisant potentiellement à une boucle infinie.
Bien qu'il soit recommandé de verrouiller les variables pour des raisons de sécurité des threads, le .NET Le runtime est conçu pour éliminer les problèmes liés à la mémoire volatile. Cependant, selon les experts en la matière, le comportement observé dans l'exemple fourni n'est pas garanti par la spécification.
L'exemple de code présente une valeur booléenne (arrêt) partagée entre deux fils. Un thread définit la valeur sur true après un délai de 5 secondes, tandis qu'un autre thread lit en continu la valeur dans une boucle. Théoriquement, sans synchronisation appropriée (par exemple, un verrou), le thread de lecture pourrait potentiellement mettre en cache la fausse valeur initiale et ne jamais lire la vraie valeur mise à jour.
Malgré les affirmations du articles, un contre-exemple reproductible a été démontré :
// using System.Threading; private static bool stopping = false; // Make volatile to fix the issue static void DoWork() { int i = 0; while (!stopping) { i++; } Console.WriteLine("DoWork exit " + i); }
Dans ce scénario, après avoir défini l'arrêt sur true, le thread DoWork continue de s'exécuter indéfiniment, indiquant que l'ancienne valeur est mise en cache.
Pour garantir un comportement correct, il est crucial de marquer la variable partagée comme volatile, ce qui ajoute une barrière mémoire et empêche les optimisations qui pourraient conduire à la mise en cache. Alternativement, l'utilisation d'un verrou pour synchroniser l'accès à la variable résoudrait également le problème.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!