HttpApplicationState - ¿Por qué existe una condición de competencia si es seguro para subprocesos?

Question

Acabo de leer un artículo que describe cómo HttpApplicationState ha AcquireRead() / AcquireWrite() funciones para administrar el acceso concurrente. Se continúa explicando, que en algunas condiciones, sin embargo tenemos que utilizar un Lock() explict y Unlock() en el objeto Aplicación para evitar una condición de carrera.

Soy incapaz de entender por qué una condición de carrera debe existir para el estado de aplicación si el acceso concurrente está implícitamente manejado por el objeto.

Podría alguien explicar esto a mí? Por qué iba a necesitar utilizar Application.Lock() y Application.Unlock()? Gracias!

Answer 1

métodos

El AcquireRead y AcquireWrite están en la clase HttpApplicationStateLock interna, por lo que no los utiliza a sí mismo. Ellos sincronizar el acceso, pero sólo para un solo lectura o de escritura. A partir de su código se utiliza el bloqueo y desbloqueo de los métodos si es necesario sincronizar el acceso.

lo más habitual es que tenga que synchonise el acceso si va a cambiar algo que no es una sola lectura o escritura, como la adición de dos elementos de aplicación que dependen unos de otros, o la primera comprobación de si un elemento existe y luego añadir que:

Application.Lock()
if (Application["info"] == null) {
   Application.Add("info", FetchInfoFromDatabase());
}
Application.Unlock();

Answer 2

HttpApplicationState - donde las variables de acceso a nivel mundial los que son visibles para todos los

Los usuarios que utilizan la aplicación. Así que con el fin de evitar la condición de carrera mientras se cambia

el valor de las variables. Necesitamos un poco de precaución, es por eso que estamos utilizando

Application.Lock () y después de realizar el trabajo liberando la misma variable a otros en el

cola utilizando Application.UnLock ()

Application.Lock()
Application("VisitorCount") = Convert.ToInt32(Application("VisitorCount")) + 1
Application.UnLock()