Devrais-je verrouiller une variable dans un thread si je n’ai besoin que de sa valeur dans d’autres threads, et pourquoi ça marche si je ne le fais pas?

Je suis conscient de cette question , mais je pense que mes préoccupations sont très différentes.

J’ai récemment créé une application SDL à l’aide de threading et d’OpenGL. J’ai un fil qui tourne dans une boucle, qui met continuellement à jour l’état des objects que je dessine à l’écran. Les états sont très simples, il s’agit simplement d’un tableau booléen (lorsque la valeur du tableau est vraie, je le dessine, quand elle est fausse, ce n’est pas le cas).

Actuellement, je n’ai aucun verrou mutex sur aucune de mes variables et tout fonctionne correctement. Même si seulement la moitié du tableau d’états a été mise à jour entre un tirage, le nombre d’images par seconde est beaucoup plus élevé (ou au moins égal à) le taux de mise à jour, il serait donc acceptable d’avoir un état semi-mis à jour.

Maintenant, j’ai initialement commencé à travailler sur une idée similaire à celle-ci sur un système embarqué utilisant des interruptions. De temps en temps, une interruption se déclenche, met à jour le tableau d’états et l’exécution se poursuit. Maintenant que je suis sur un ordinateur de bureau multicœur et que je mets à jour le tableau simultanément, je me demande pourquoi rien ne se passe mal, puisque, techniquement, je lis et écris dans le même emplacement de mémoire en même temps .

  • Est-ce juste par hasard ou y a-t-il une raison pour laquelle aucune violation d’access à la mémoire ne se produit?
  • S’il est acceptable que l’état de la variable change juste avant, pendant ou juste après l’utilisation de la valeur, devrais-je utiliser un verrou mutex?

Merci de votre aide.


Edit: Informations supplémentaires – le tableau est créé de manière dynamic, mais lorsqu’il est créé / supprimé, j’utilise un mutex (j’imaginais que l’access à la mémoire supprimée ne serait pas apprécié: P).

En théorie, il est totalement invalide (comportement indéfini) d’accéder à cette mémoire sans cette synchronisation.

En pratique, il est modérément sûr tant que:

  1. Un seul fil est écrit et les autres sont tous en train de lire.
  2. Peu importe que les lecteurs voient certaines des modifications apscopes avant un certain temps (peut-être beaucoup plus tard que l’heure à laquelle ils ont été écrits.
  3. Peu importe que les lecteurs voient des modifications non conformes, c’est-à-dire qu’ils voient certaines modifications apscopes ultérieurement sans voir les autres modifications apscopes précédemment.

Les problèmes 2 et 3 ne concernent pas x86, mais peuvent se produire sur presque toutes les autres machines multi-core / SMP du monde réel. Vous pouvez les atténuer avec des asm (ou des composants insortingnsèques du compilateur) spécifiques à la machine pour insérer des barrières de mémoire aux points appropriés.

Les éléments du tableau booléen peuvent être définis / lus avec une opération atomique, un mutex n’est pas nécessaire. Vous avez besoin d’un mutex pour protéger une structure afin de garantir sa cohérence. Puisque vos booléens sont indépendants, il n’y a pas de problème.