Disons que j'ai une variable x (de type myClass), qui est initialement null et une affectation.net: Attribue-t-on un objet atomique de référence (c'est-à-dire thread-safe)?
x = myObject
exactement une fois survenant dans un fil d'arrière-plan.
Est-il garanti que x contient toujours null ou myObject lorsqu'il est accédé depuis le thread principal? Ou est-il possible que x contienne des données invalides sous peu?
Si la taille de la référence de type est de la même taille que la taille de mot native de la CPU, l'affectation sera atomique (et sécurisée dans votre scénario décrit).
En fait, (n'ont pas la référence à la main) Je suis assez certain qu'un type ref aura toujours la même taille que la taille du mot de CPU natif.
Voici la référence: Partition I, Section 12.6.6 des états CLI spec : 'Une CLI conforme doit garantir que l'accès en lecture et en écriture à des emplacements de mémoire correctement alignés ne dépasse pas la taille du mot natif lorsque tous les accès en écriture à un emplacement ont la même taille. Même sans citer les spécifications, vous avez été le premier à fournir une réponse correcte. –
@Darin Dimitrov: je ne sais pas pourquoi vous avez supprimé votre réponse, il était correct après tout. –
J'ai supprimé ma réponse car elle ne fournit aucune information utile supplémentaire à votre réponse. –
De this (bien qu'il traite un sujet un peu différent) Je conclus que les affectations sont atomc.
vérifier cet article http://msmvps.com/blogs/luisabreu/archive/2009/06/29/multithreading-hardware-atomicity.aspx –