HttpModule se reparte entre los hilos de trabajo?

Question

¿Tengo que bloqueo de acceso a los miembros de instancia?

Ejemplo:

public class HttpModule : IHttpModule
{
    //...

    Dictionary<int, int> foo;

    void UseFoo(int a, int b)
    {
        foo[a] = b;
    }
}

Answer 1

¡No es claro para mí hasta ahora a partir de la documentación de MSDN, pero me encontré con un mensaje en el foro de alguien que dice saber la respuesta . Parece que usted no debe esperar cosas malas para pasar con su aplicación, pero se debe tener en cuenta que el estado de foo no necesariamente se comparte a través de todos los resultados, ya que se creará su HttpModule una vez por HttpApplication que IIS opta por mantener en su piscina.

Answer 2

quería ofrecer aquí mis hallazgos relacionados a esta pregunta como he observado en IIS6:

He estado tratando con este tema extensamente en IIS6 y han encontrado algunos resultados interesantes que utilizan log4net y la reflexión de la historia de ejecución de captura. Lo que he encontrado es que hay una extensa 'gestión de hilos' pasando detrás de las escenas. Parece que hay una serie de 'primaria' de hilos que corresponden 1: 1 a HttpApplication. Estos hilos sin embargo a no manejamos exclusivamente la tubería de su solicitud. Varios diferentes sub-hilos pueden ser llamados cuando se accede a estos casos. Con posterioridad nuevas solicitudes y peticiones de recursos utilizados por su aplicación parecen compartir cierta información persistente en relación con su solicitud original, pero están sin embargo nunca manejado enteramente por el hilo inicial que indica algún tipo de relación. No podía discernir cualquier patrón de hormigón (con excepción de lo que he descrito anteriormente) en cuanto a qué elementos se repartieron a otros temas como lo fue aparentemente al azar. Mi conclusión de esta evidencia es que hay algún concepto de agrupación jerárquica? que ocurren donde algún subconjunto desconocido de elementos de referencia se heredan en los hilos del niño a través de la referencia de los padres.

Así como una respuesta diría que HttpModules son compartida entre los hilos. En términos de bloqueo de valores de instancia, esto sería aplicable si los valores se aplican a todas las solicitudes que utilizan el módulo y deben mantener un cierto estado. Pude ver este ser útil si el intento de mantener los valores de instancia con estado que son caros para determinar de modo que pudieran ser reutilizados en las solicitudes posteriores.

Este problema me había estado molestando desde hace algún tiempo es de esperar que esta información ayude a alguien.

Answer 3

He encontrado recientemente un artículo que toca en esta pregunta un poco: http://www.dominicpettifer.co.uk/Blog/41/ihttpmodule-gotchas---the-init---method-can-get-called-multiple-times

No menciona hilos, pero sólo dice que el proceso de trabajo será

  

instantiate hasta HttpApplication   objetos como se piensa que necesita, a continuación,   que va a sumarlos para obtener un rendimiento   razones, instancias de reutilización como nuevo   peticiones vienen en antes de enviarlos   nuevo en la piscina.

Tras el código en el enlace, se puede estar seguro de que su código de inicio se ejecuta una vez de una manera segura para los subprocesos:

private static bool HasAppStarted = false; 
private readonly static object _syncObject = new object(); 

public void Init(HttpApplication context) 
{ 
    if (!HasAppStarted) 
    { 
        lock (_syncObject) 
        { 
            if (!HasAppStarted) 
            { 
                // Run application StartUp code here 

                HasAppStarted = true; 
            } 
        } 
    } 
}

he tenido la intención de establecer una aplicación de prueba para ejecutar esta prueba y que, sólo para ver si es verdad, pero no he tenido tiempo.

Answer 4

El artículo publicado por Jim es interesante, pero como dice Jim no menciona nada acerca de la seguridad hilo.

Creo que se necesitaría solamente el mecanismo de bloqueo si va a inicializar los miembros estáticos o la realización de "una sola vez" inicializaciones es decir, la inicialización de un recurso estático.

No podría concluir a partir de MSDN ni el artículo mencionado por Jim que necesitamos el mecanismo de bloqueo en la inicialización de las variables de clase no estáticos.