Méthodes System.Threading.Monitor.Wait

méthode Wait(Object, Int32, Boolean)

Cette méthode ne retourne pas tant qu’elle ne réacquire pas un verrou exclusif sur le obj paramètre.

Le thread qui possède actuellement le verrou sur l’objet spécifié appelle cette méthode pour libérer l’objet afin qu’un autre thread puisse y accéder. L'appelant est bloqué en attendant de réacquérir le verrou. Cette méthode est appelée lorsque l’appelant doit attendre une modification d’état qui se produira à la suite des opérations d’un autre thread.

Le délai d’attente garantit que le thread actuel ne bloque pas indéfiniment si un autre thread libère le verrou sans appeler d’abord la méthode Pulse ou PulseAll. Il déplace également le thread vers la file d’attente prête, contournant les autres threads devant lui dans la file d’attente, afin qu’il puisse réacquérir le verrou plus tôt. Le thread peut tester la valeur de retour de la méthode Wait pour déterminer s’il a réacquis le verrou avant le délai d’attente. Le thread peut évaluer les conditions qui l'ont conduit à entrer en attente et, si nécessaire, appeler la méthode Wait à nouveau.

Lorsqu’un thread appelle Wait, il libère le verrou et entre dans la file d’attente. À ce stade, le thread suivant dans la file d’attente prête (s’il en existe un) est autorisé à prendre le contrôle du verrou. Le thread qui a appelé Wait reste dans la file d’attente tant qu’un thread qui détient le verrou n’a pas appelé PulseAll, ou bien qu’il soit le suivant dans la file d’attente et qu’un thread qui détient le verrou n’ait appelé Pulse. Toutefois, si millisecondsTimeout s’écoule avant qu’un autre thread appelle la méthode Pulse ou PulseAll de cet objet, le thread d’origine est déplacé vers la file d’attente prête pour récupérer le verrou.

L'appelant exécute Wait une seule fois, quel que soit le nombre de fois où Enter a été appelé pour l'objet spécifié. Conceptuellement, la Wait méthode stocke le nombre de fois où l'appelant a invoqué Enter sur l'objet et appelle Exit autant de fois que nécessaire pour libérer complètement l'objet verrouillé. L'appelant se bloque ensuite en attendant de réacquérir l'objet. Lorsque l’appelant réacquire le verrou, le système appelle Enter autant de fois que nécessaire pour restaurer le nombre enregistré Enter pour l’appelant. L’appel Wait libère le verrou de l’objet spécifié uniquement ; si l’appelant est le propriétaire des verrous sur d’autres objets, ces verrous ne sont pas libérés.

Les méthodes Pulse, PulseAll et Wait doivent être appelées à partir d’un bloc de code synchronisé.

Les remarques de la Pulse méthode expliquent ce qui se passe si Pulse elle est appelée quand aucun thread n’attend.

méthode Wait(Object, TimeSpan, Boolean)

Cette méthode ne retourne pas tant qu’elle ne réacquire pas un verrou exclusif sur le obj paramètre.

Le thread qui possède actuellement le verrou sur l’objet spécifié appelle cette méthode pour libérer l’objet afin qu’un autre thread puisse y accéder. L'appelant est bloqué en attendant de réacquérir le verrou. Cette méthode est appelée lorsque l’appelant doit attendre une modification d’état qui se produira à la suite des opérations d’un autre thread.

Le délai d’attente garantit que le thread actuel ne bloque pas indéfiniment si un autre thread libère le verrou sans appeler d’abord la méthode Pulse ou PulseAll. Il déplace également le thread vers la file d’attente prête, contournant les autres threads devant lui dans la file d’attente, afin qu’il puisse réacquérir le verrou plus tôt. Le thread peut tester la valeur de retour de la méthode Wait pour déterminer s’il a réacquis le verrou avant le délai d’attente. Le thread peut évaluer les conditions qui l'ont conduit à entrer en attente et, si nécessaire, appeler la méthode Wait à nouveau.

Lorsqu’un thread appelle Wait, il libère le verrou et entre dans la file d’attente. À ce stade, le thread suivant dans la file d’attente prête (s’il en existe un) est autorisé à prendre le contrôle du verrou. Le thread qui a appelé Wait reste dans la file d’attente tant qu’un thread qui détient le verrou n’a pas appelé PulseAll, ou bien qu’il soit le suivant dans la file d’attente et qu’un thread qui détient le verrou n’ait appelé Pulse. Toutefois, si timeout millisecondes s'écoulent avant qu'un autre thread appelle la méthode Pulse ou PulseAll de cet objet, le thread d'origine est déplacé vers la file d'attente prête afin de récupérer le verrou.

L'appelant exécute Wait une seule fois, quel que soit le nombre de fois où Enter a été appelé pour l'objet spécifié. Conceptuellement, la Wait méthode stocke le nombre de fois où l'appelant a invoqué Enter sur l'objet et appelle Exit autant de fois que nécessaire pour libérer complètement l'objet verrouillé. L'appelant se bloque ensuite en attendant de réacquérir l'objet. Lorsque l’appelant réacquire le verrou, le système appelle Enter autant de fois que nécessaire pour restaurer le nombre enregistré Enter pour l’appelant. L’appel Wait libère le verrou de l’objet spécifié uniquement ; si l’appelant est le propriétaire des verrous sur d’autres objets, ces verrous ne sont pas libérés.

Les méthodes Pulse, PulseAll et Wait doivent être appelées à partir d’un bloc de code synchronisé.

Les remarques de la Pulse méthode expliquent ce qui se passe si Pulse elle est appelée quand aucun thread n’attend.

Quitter le contexte

LeexitContext paramètre n’a aucun effet, sauf si la Wait méthode est appelée à partir d’un contexte managé nondefault. Cela peut se produire si votre thread se trouve à l’intérieur d’un appel à une instance d’une classe dérivée de ContextBoundObject. Même si vous exécutez actuellement une méthode sur une classe qui n’est pas dérivée de ContextBoundObject, comme String, vous pouvez être dans un contexte non par défaut si une ContextBoundObject est sur votre pile dans le domaine d'application.

Lorsque votre code s’exécute dans un contexte non défini, en spécifiant true pour exitContext que le thread quitte le contexte managé non défini (autrement dit, pour passer au contexte par défaut) avant d’exécuter la Wait méthode. Elle retourne au contexte non par défaut d’origine après l’exécution de l’appel à la méthode Wait.

Cela peut être utile lorsque la classe liée au contexte a l’attribut SynchronizationAttribute appliqué. Dans ce cas, tous les appels aux membres de la classe sont automatiquement synchronisés et le domaine de synchronisation est le corps entier du code de la classe. Si le code dans la pile des appels d’un membre appelle la Wait méthode et spécifie true pour exitContext, le thread quitte le domaine de synchronisation, ce qui permet à un thread bloqué sur un appel à n’importe quel membre de l’objet de continuer. Lorsque la Wait méthode est retournée, le thread qui a effectué l’appel doit attendre de réentérer le domaine de synchronisation.