Je lisais Cet article MSDN sur la synchronisation du fil sans verrouillage . L'article semble déduire que tant que vous entrez dans une serrure avant d'accéder aux variables partagées, ces variables seront à jour (dans .NET 2.0 au moins).
Je dois penser à comment cela était possible? Un verrouillage de .NET est juste un objet arbitraire que tous les threads vérifient avant d'accéder à la mémoire, mais la serrure elle-même n'a aucune connaissance des emplacements de mémoire qui sont accessibles.
Si j'ai un thread mettant une mise à jour d'une variable, ou même une pièce de mémoire totale, comment les mises à jour sont-elles garanties de CPU CACHES lors de la saisie / sortant d'une serrure? Tous les accès mémoire sont-ils efficacement volatils à l'intérieur de la serrure?
4 Réponses :
Vérifiez le travail d'Eric LIPPERT: http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatuas-At-Immutabilité-Afférent-partability.aspx
verrouille garantissant que la mémoire lue ou modifiée à l'intérieur de la serrure est observée pour être cohérente, les verrous garantissent qu'un seul thread accède à un morceau de mémoire donné à la fois, etc.
Alors oui, tant que vous verrouillez chaque fois avant d'accéder à des ressources partagées, vous pouvez être sûr de sa date à jour
edit Recherchez le message suivant pour plus d'informations et une vue d'ensemble très utile: http://igoro.com/archive/volatile-keyword-in-c-memory-model-explé/
Liens intéressants, merci. N'a pas réalisé que tous les écrit C # sont volatils! Le deuxième lien répond à ma question. Les accès à la mémoire ne sont pas volatils dans la serrure, mais la libération d'une serrure écrit et l'obtention d'un verrouille chasse le cache de lecture, ainsi que des valeurs sont à jour.
Cela se réfère-t-il à toutes sortes de verrous que des fournissements .NET, y compris Mutex, moniteur, ReaderWratterLock, etc.?
Eh bien, l'article l'explique:
lisons ne peut pas se déplacer avant d'entrer dans une serrure.
écrit ne peut pas bouger après avoir sorti d'une serrure.
et plus d'explication du même article:
Lorsqu'un thread sort de la serrure, la troisième règle garantit que toutes les écrivies effectuées tandis que le verrou était maintenu est visible à tous les processeurs. Avant que la mémoire soit accessible par un autre thread, le thread de lecture entrera dans une serrure et la deuxième règle garantit que les lectures se produisent logiquement après la prise du verrou.
Tout-la partie de la mémoire C # lit et écrit sont volatils, non. (Imaginez si c'était le cas Performance-Wise!)
mais.
Comment ces mises à jour sont-elles garanties pour être rinçues des caches CPU lors de la saisie / sortant d'un verrou
CACHES CPU sont spécifiques à la CPU, mais elles ont tous une forme de protocole de cohérence de mémoire . C'est-à-dire que lorsque vous accédez à une mémoire d'un noyau, s'il est présent dans un autre cache principal, le protocole utilisé par la CPU s'assurera que les données sont livrées au noyau local.
Ce que Petar Ivanov fait allusion à sa réponse est cependant très pertinent. Vous devriez consulter Modèle de cohérence de la mémoire si vous souhaitez comprendre plus ce que son point est.
Maintenant, comment C # garantit que la mémoire est à jour est à la hauteur des implémentations C # et Eric Lippert's Blog est certainement un bon endroit pour comprendre les problèmes sous-jacents.
Je ne suis pas sûr de l'état des choses dans .NET, mais en Java, il est clairement indiqué que des deux threads coopérants de manière à ce que doivent utiliser l'objet même pour le verrouillage afin de Profitez de ce que vous dites dans votre relevé introductif, pas seulement de tout verrouillage. C'est une distinction cruciale à faire.
Un verrou n'a pas besoin de "savoir" ce qu'il protège; Il doit simplement s'assurer que tout ce qui a été écrit par le casier précédent est mis à la disposition d'un autre casier avant de le laisser continuer.
Ce n'est pas une zone que j'ai beaucoup d'expérience avec mais pourquoi est-il important de savoir si l'emplacement de la mémoire que vous accédez est dans le cache de la CPU ou non.
@Benrobinson - Supposons que vous disposiez de 2 threads fonctionnant sur différents noyaux accédant à 1 entier sur le tas. Dans ce cas, chaque thread pourrait stocker une copie de la valeur dans le cache du noyau local, à moins que des méthodes de synchronisation appropriées soient appliquées.