La documentación de MSDN dice de los "exitContext" parámetro booleano:Monitor.Wait y el parámetro "exitContext"
cierto para salir y readquirir el dominio de sincronización para el contexto (si está en un contexto sincronizado) antes de la espera; de lo contrario, falso.
No sigo. Suponiendo que ya entiendo el pulso y espero, ¿alguien puede dar una explicación de este parámetro? Un ejemplo práctico de sería bastante valioso.
Es una verruga muy antigua en los frameworks .net; acaba de pasar en falso y seguir adelante.
El "contexto" al que se refieren es un contexto remoto. Puede intentar ejecutar ese concepto buscando ContextBoundObject en MSDN; esto te llevará a todo tipo de cosas interesantes. En un punto del diseño de la CLR, estos "contextos de objetos" iban a ser mucho más importantes de lo que realmente terminaron siendo; muchas personas olvidaron que existían en primer lugar, y la única API que la mayoría de la gente encuentra que tiene algo que ver con CBO es Monitor.Wait.
Así que simplemente pase el falso y continúe. :)
Podemos ir aún más profundo si quieres ...
Hubo una noción de la configuración de uno de estos contextos objeto a ser "sincronizado". Resulta que en el CLR, cada hilo tiene un contexto lógico de llamada asociado. Cuando realiza una llamada a un método con comunicación remota, este contexto de llamada lógica se pasa junto con la llamada, de modo que el CLR en el otro lado del límite remoto puede tratar el subproceso que procesa la solicitud como lógicamente el mismo subproceso. Si el objeto al que se llama (el que se encuentra al otro lado del límite remoto) vuelve a llamar al objeto original, esa segunda llamada puede estar en un hilo físico diferente. Sin embargo, debido a que el contexto de llamada lógica fluyó junto con la llamada remota, esa segunda cadena física puede volver a entrar en el contexto "sincronizado".
Un ejemplo de esto es muy complejo de tratar de escribir aquí. Puedo escribir uno por encargo, pero ...
Es una verruga muy antigua en los frameworks .net; acaba de pasar en falso y seguir adelante. :)
Es relevante en escenarios remotos, pasar verdadero permite que se entregue otra llamada. Este mismo argumento fue también la razón por la que se agregó la sobrecarga WaitHandle.WaitOne (int) a .NET 2.0 SP1. Una compatibilidad rompiendo el cambio que causó mucha miseria. Anteriormente solo estaba disponible la sobrecarga de WaitOne (int, bool) y nadie sabía qué significaba ese argumento exitContext.
Pasando false es el uso normal. Me considero agradablemente ignorante de cualquier ejemplo práctico donde usar verdadero podría tener sentido o llegar a un buen final. Remoting es en esencia bastante complicado y mal documentado. WCF lo hizo irrelevante.