Exporter (0) Imprimer
Développer tout

Monitor, classe

Fournit un mécanisme qui synchronise l'accès aux objets.

Espace de noms: System.Threading
Assembly : mscorlib (dans mscorlib.dll)

[ComVisibleAttribute(true)] 
public static class Monitor
/** @attribute ComVisibleAttribute(true) */ 
public final class Monitor
ComVisibleAttribute(true) 
public final class Monitor
Non applicable.

RemarqueRemarque :

L'attribut HostProtectionAttribute appliqué à cette classe a la valeur de propriété Resources suivante : Synchronization | ExternalThreading. HostProtectionAttribute n'affecte pas les applications bureautiques (qui sont généralement démarrées en double-cliquant sur une icône, en tapant une commande ou en entrant une URL dans un navigateur). Pour plus d'informations, consultez la classe HostProtectionAttribute ou Attributs de programmation et de protection des hôtes SQL Server.

La classe Monitor contrôle l'accès aux objets en fournissant à un seul thread le verrou d'un objet. Les verrous posés sur les objets permettent de restreindre l'accès à un bloc de code communément appelé une section critique. Tant qu'un thread possède le verrou d'un objet, aucun autre thread ne peut acquérir ce verrou. Vous pouvez également utiliser Monitor pour garantir qu'aucun autre thread n'est autorisé à accéder à une section du code d'application exécuté par le propriétaire du verrou, sauf si cet autre thread exécute le code en utilisant un objet verrouillé différent.

RemarqueRemarque :

Utilisez Monitor pour bloquer des objets (c'est-à-dire des types référence) mais pas des types valeur. Pour plus d'informations, consultez Enter et la rubrique conceptuelle Moniteurs.

Monitor comprend les fonctionnalités suivantes :

  • Il est associé à un objet à la demande.

  • Il est indépendant, ce qui signifie qu'il peut être appelé directement à partir d'un contexte quelconque.

  • Il n'est pas possible de créer une instance de la classe Monitor.

Les informations suivantes sont gérées pour chaque objet synchronisé :

  • Référence au thread qui contient actuellement le verrou.

  • Référence à une file d'attente opérationnelle qui contient les threads prêts à obtenir le verrou.

  • Référence à une file d'attente en suspens qui contient les threads en attente d'une notification de modification d'état de l'objet verrouillé.

Le tableau suivant décrit les actions pouvant être entreprises par des threads qui accèdent à des objets synchronisés :

Action

Description

Enter, TryEnter

Acquiert un verrou pour un objet. Cette action marque également le début d'une section critique. Aucun autre thread ne peut pénétrer dans la section critique, sauf s'il exécute les instructions de la section critique à l'aide d'un objet verrouillé différent.

Wait

Libère le verrou d'un objet pour permettre à d'autres threads de verrouiller cet objet et d'y accéder. Le thread appelant attend qu'un autre thread accède à l'objet. Des signaux d'impulsion sont utilisés pour avertir les threads en attente des modifications d'état d'un objet.

Pulse (signal), PulseAll

Envoie un signal à un ou plusieurs threads en attente. Ce signal avertit un thread en attente que l'état de l'objet verrouillé a changé et que le propriétaire du verrou est prêt à libérer le verrou. Le thread en attente est placé dans la file d'attente opérationnelle de l'objet de sorte qu'il peut finir par recevoir le verrou pour l'objet. Une fois en possession du verrou, le thread peut vérifier le nouvel état de l'objet pour savoir si l'état requis est atteint.

Exit

Libère le verrou d'un objet. Cette action marque également la fin d'une section critique protégée par l'objet verrouillé.

Utilisez les méthodes Enter et Exit pour marquer le début et la fin d'une section critique. Si la section critique est un jeu d'instructions contiguës, le verrou acquis par la méthode Enter garantit qu'un seul thread peut exécuter le code de la section critique avec l'objet verrouillé. Dans ce cas, il est recommandé de placer les instructions concernées dans un bloc try et de placer l'instruction Exit dans un bloc finally. Ce service est généralement utilisé pour synchroniser l'accès à une méthode statique ou une méthode d'instance d'une classe. Si une méthode d'instance nécessite un accès synchronisé aux threads, elle appelle les méthodes Enter et Exit correspondantes en utilisant l'instance actuelle comme objet à verrouiller. Dans la mesure où un seul thread peut contenir le verrou de l'instance actuelle, la méthode ne peut être exécutée que par un thread à la fois. Les méthodes statiques sont protégées de manière similaire en utilisant le Type de l'instance actuelle comme objet verrouillé. Les fonctionnalités fournies par les méthodes Enter et Exit sont identiques à celles qui sont fournies par l'instruction lock C# (SyncLock en Visual Basic), mais lock et SyncLock encapsulent la méthode Exit dans un bloc tryfinally (TryFinally en Visual Basic) pour garantir que le moniteur est libéré.

Si une section critique s'étend sur l'ensemble d'une méthode, le service de verrouillage décrit plus haut peut être assuré en plaçant System.Runtime.CompilerServices.MethodImplAttribute sur la méthode et en spécifiant la valeur Synchronized dans le constructeur de MethodImplAttribute. Cet attribut permet de se passer des instructions Enter et Exit. Notez que cet attribut maintient le verrou dans le thread en cours jusqu'au retour de la méthode ; si le verrou peut être libéré plus tôt, utilisez de préférence la classe Monitor ou l'instruction C# lock.

Les instructions Enter et Exit qui verrouillent et libèrent un objet donné ont la possibilité de franchir les limites de membre et de classe, mais cette pratique n'est pas recommandée.

Lorsque vous sélectionnez un objet sur lequel effectuer une synchronisation, vous avez intérêt à poser des verrous sur des objets privés ou internes uniquement. Le verrouillage d'objets externes risque de provoquer des blocages dans la mesure où un code non lié peut choisir de verrouiller les mêmes objets à des fins différentes.

System.Object
  System.Threading.Monitor

Ce type est thread-safe.

Windows 98, Windows Server 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile pour Pocket PC, Windows Mobile pour Smartphone, Windows Server 2003, Windows XP Édition Media Center, Windows XP Professionnel Édition x64, Windows XP SP2, Windows XP Starter Edition

Microsoft .NET Framework 3.0 est pris en charge sur Windows Vista, Microsoft Windows XP SP2 et Windows Server 2003 SP1.

.NET Framework

Prise en charge dans : 3.0, 2.0, 1.1, 1.0

.NET Compact Framework

Prise en charge dans : 2.0, 1.0

XNA Framework

Prise en charge dans : 1.0

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft