La documentation MSDN dit du paramètre booléen « exitContext » « exitContext »:Monitor.Wait et le paramètre
vrai pour quitter et réacquérir le domaine de synchronisation pour le contexte (si dans un contexte synchronisé) avant l'attente; sinon, faux.
Je ne suis pas. En supposant que je comprends déjà le pouls et attendre, quelqu'un peut-il donner une explication de ce paramètre? Un pratique exemple de son utilisation serait très utile.
C'est une très ancienne verrue dans les frameworks .net; il suffit de passer en faux et de passer à autre chose.
Le "contexte" auquel ils font référence est un contexte d'accès distant. Vous pouvez essayer de vider ce concept en recherchant ContextBoundObject dans MSDN; Cela vous mènera à toutes sortes de choses intéressantes. À un moment donné de la conception du CLR, ces «contextes d'objets» allaient être beaucoup plus importants qu'ils ne l'étaient réellement; Beaucoup de gens ont oublié qu'ils existaient en premier lieu, et la seule API que la plupart des gens rencontrent et qui a quelque chose à voir avec les CBO est Monitor.Wait.
Donc il suffit de passer en faux et de passer à autre chose. :)
Nous pouvons aller encore plus loin si vous voulez ...
Il y avait une notion de configuration d'un de ces contextes d'objet à « synchronisé ». Il s'avère que dans le CLR, chaque thread a un contexte d'appel logique qui lui est associé. Lorsque vous effectuez un appel de méthode avec un accès distant, ce contexte d'appel logique est transmis avec l'appel, de sorte que le CLR de l'autre côté de la limite d'accès peut traiter le thread traitant la requête comme étant logiquement le même thread. Si l'objet appelé (celui de l'autre côté de la frontière d'accès distant) rappelle dans l'objet original, alors ce deuxième appel peut être sur un fil physique différent. Toutefois, étant donné que le contexte d'appel logique a coulé avec l'appel distant, ce deuxième thread physique peut entrer à nouveau dans le contexte "synchronisé".
Un exemple de ceci est loin de complexe pour essayer d'écrire ici. Je peux en écrire un pour vous sur demande, mais ...
C'est une très ancienne verrue dans les frameworks .net; il suffit de passer en faux et de passer à autre chose. :)
Il est pertinent dans les scénarios d'accès distant, le passage à true permet de délivrer un autre appel. Ce même argument était également la raison pour laquelle la surcharge WaitHandle.WaitOne (int) a été ajoutée à .NET 2.0 SP1. Un changement de compatibilité qui a causé beaucoup de misère. Auparavant, seule la surcharge WaitOne (int, bool) était disponible et personne ne savait ce que signifiait cet argument exitContext.
Passer à false est l'utilisation normale. Je me considère agréablement ignorant de tout exemple pratique où l'utilisation vrai pourrait soit faire sens ou arriver à une bonne fin. Remoting est à la base assez compliqué et mal documenté. WCF l'a rendu non pertinent.