Quand utiliser le verrouillage vs MemoryBarrier dans .NET

Question

Dans .NET le mot-clé lock est le sucre syntaxique autour Monitor.Enter et Monitor.Exit, donc on peut dire que ce code

lock(locker)
{
  // Do something
}

est le même que

Monitor.Enter(locker);
try
{
  // Do Something
}
finally
{
  Monitor.Exit(locker);
}

Cependant, le framework .NET comprend également la classe MemoryBarrier qui fonctionne d'une manière similaire

Thread.MemoryBarrier();
//Do something
Thread.MemoryBarrier();

Je suis confus quand je voudrais utiliser Thread.MemoryBarrier sur la version lock / Monitor? Je suis encore plus confus par un Threading Tutoriel qui indique qu'ils fonctionnent lLa même.

Pour autant que je peux voir la différence visible est un objet n'ayant pas besoin de verrouillage, que je suppose que l'utilisation Monitor vous pouvez faire quelque chose dans les threads où MemoryBarrier est sur un seul thread.

Mon instinct me dit qu'une autre différence clé est MemoryBarrier est pour les variables et non pour les méthodes.

Enfin ce n'est pas lié à la question actuelle Quand utiliser 'volatile' ou 'Thread.MemoryBarrier ()' dans threadsafe code de verrouillage? (C #) , comme qui se concentre sur le mot-clé volatile que je comprends son utilisation de.

Answer 1

À mon avis, vous devriez presque jamais utiliser Thread.MemoryBarrier. Il est utilisé pour sans verrou Code - faire en sorte que les modifications apportées à un fil sont visibles à l'autre sans encourir le coût d'une serrure. Finalité pas synchronisation des threads de contrôle, à la différence lock. Je ne vois pas où dans le tutoriel de Joe, il dit que MemoryBarrier « fonctionne de la même » que lock. Pourriez-vous nous expliquer où vous êtes exactement obtenir cette impression?

À mon avis, du code bas sans verrouillage de niveau est trop difficile pour presque tout le monde autre que les développeurs dont les compétences principale est la concurrence. Si je veux écrire un code sans verrouillage, je vais utiliser les blocs de construction de niveau supérieur construit par les développeurs (tels que les extensions parallèles dans .NET 4.0) plutôt que d'essayer de rouler mon propre.

À titre d'exemple, j'ai récemment eu mes yeux ouverts à la signification précise de volatile qui ne sont pas « toujours lu de la mémoire principale, toujours écrire directement dans la mémoire principale ». (Mon tutoriel de thread a encore cette explication au moment - quelque chose que je dois fixer à un moment donné.) Il est beaucoup plus subtile que celle . Cela signifie que certains de mes utilisations antérieures de volatile pourraient bien être incorrectes.