Méthodes System.Threading.Monitor.Wait

Cet article vous offre des remarques complémentaires à la documentation de référence pour cette API.

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é lors de l’attente de reacquire 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 ou PulseAll la Pulse méthode. 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éactiver le verrou plus tôt. Le thread peut tester la valeur de retour de la Wait méthode pour déterminer s’il a reacquiré le verrou avant le délai d’attente. Le thread peut évaluer les conditions qui l’ont provoqué pour entrer dans l’attente et, si nécessaire, appeler à nouveau la Wait méthode.

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 jusqu’à ce qu’un thread qui contient le verrou appelle PulseAll, soit qu’il s’agisse du suivant dans la file d’attente et d’un thread qui contient les appels Pulsede verrou . Toutefois, s’il millisecondsTimeout s’écoule avant qu’un autre thread appelle l’objet ou PulseAll la méthode de cet objet, le thread d’origine est déplacé vers la file d’attente Pulse prête pour récupérer le verrou.

L’appelant s’exécute Wait une seule fois, quel que soit le nombre de fois Enter qui a été appelé pour l’objet spécifié. Conceptuellement, la Wait méthode stocke le nombre de fois où l’appelant est Enter appelé sur l’objet et appelle Exit autant de fois que nécessaire pour libérer entièrement l’objet verrouillé. L’appelant bloque ensuite en attendant de réacquire 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 Pulseméthodes et Wait les méthodes PulseAlldoivent ê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é lors de l’attente de reacquire 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 ou PulseAll la Pulse méthode. 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éactiver le verrou plus tôt. Le thread peut tester la valeur de retour de la Wait méthode pour déterminer s’il a reacquiré le verrou avant le délai d’attente. Le thread peut évaluer les conditions qui l’ont provoqué pour entrer dans l’attente et, si nécessaire, appeler à nouveau la Wait méthode.

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 jusqu’à ce qu’un thread qui contient le verrou appelle PulseAll, soit qu’il s’agisse du suivant dans la file d’attente et d’un thread qui contient les appels Pulsede verrou . Toutefois, si timeout des millisecondes s’écoulent avant qu’un autre thread appelle l’objet ou PulseAll la méthode de cet objet, le thread d’origine est déplacé vers la file d’attente Pulse prête pour récupérer le verrou.

L’appelant s’exécute Wait une seule fois, quel que soit le nombre de fois Enter qui a été appelé pour l’objet spécifié. Conceptuellement, la Wait méthode stocke le nombre de fois où l’appelant est Enter appelé sur l’objet et appelle Exit autant de fois que nécessaire pour libérer entièrement l’objet verrouillé. L’appelant bloque ensuite en attendant de réacquire 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 Pulseméthodes et Wait les méthodes PulseAlldoivent ê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 ContextBoundObjectde , par Stringexemple, vous pouvez être dans un contexte nondefault si une ContextBoundObject est sur votre pile dans le domaine d’application actuel.

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 nondefault d’origine après l’exécution de l’appel à la Wait méthode.

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.